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In this Issue 



Bin the early days of factory automation, it was a lot easier to automate individual 
processes or workcells than an entire factory. The result was islands of auto- 
mation, each representing the best available solution to an individual need but 
incapable of communicating easily with other islands or with higher-level sys- 
tems because of differences in computers, interfaces, languages, operating 
systems, and applications. Yet the goal has always been the integrated factory, 
or CIM — computer-integrated manufacturing. The development of advanced 
networks and communication protocols such as MAP (see the August 1990 
issue) has brought the integrated factory closer to realization, but it can still be 
a formidable task for a system integrator to provide for transparent communica- 
tions between diverse applications designed for different computing platforms. HP Sockets, our cover 
subject, is a product that helps system integrators overcome incompatibilities and provide file and mes- 
sage transfer between applications running on different network nodes. HP Sockets runs on and provides 
communication between HP computers using the HP-UX and MPE XL operating systems. It can also com- 
municate with non-HP systems through a gateway, an HP-UX node that uses a client/server model to ex- 
tend HP Sockets capabilities to machines not using the MPE XL or HP-UX operating systems. Using HP 
Sockets, a system integrator creates application adapters, which allow applications to "plug into" the HP 
Sockets system. Data coming from an application is translated to an internal common data representation 
format. Outgoing data is converted from this format to the format expected by the destination application. 
The system provides a data manipulator to resolve differences in data structures and languages and a 
data transporter to move the data from origin to destination, guided by user-created configuration files 
describing the environment. The full story of HP Sockets design, operation, and performance can be found 
in the article on page 6. 

With the use of structured analysis and structured design becoming commonplace in software engineering, 
where do we find the leading edge today in industrial software development methods? One range of methods 
that's definitely leading-edge is rigorous software engineering, also called formal methods — rigorous, abstract 
mathematics applied to software specification in an attempt to head off defects right at the start. HP Laborato- 
ries in Bristol, England has been working on formal methods for several years, and one of these methods — the 
HP Specification Language, or HP-SL — has reached a stage of development where it's ready to be used in real- 
world software projects. The idea is to develop an abstract but precise description of the behavior of the soft- 
ware system. This description can be reviewed to ensure that the system works properly and that defects are 
not introduced because of deficiencies in specifying the required behavior. Although software behavior can be 
specified using a natural language, it's difficult to do so unambiguously. Formal specification languages like 
HP-SL use special syntax and special symbols based on discrete mathematics to avoid the ambiguities of natu- 
ral language. The motivation for this approach and an overview of the symbols and syntax of HP-SL can be 
found in the article on page 24. Examples illustrating the use of HP-SL are presented in the articles on pages 32 
and 40, which show how an electronic mail system and a real-time alarm monitor are specified. In the articles 
on pages 46 and 51, software engineers from two HP product divisions relate their experiences with HP-SL in 
actual product development projects. 
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Network monitoring can mean many things, depending on the type of network and the reasons for monitoring. 
Some typical objectives of network monitoring are to measure traffic and plan for future needs, to determine 
the quality of service, and to identify and locate faults. More and more, network monitoring is a distributed pro- 
cess, with measuring devices permanently installed throughout the network reporting to a central computer. 
The HP E3500A telecommunications network monitoring system described in the article on page 59 is a distrib- 
uted system for monitoring telephone networks, mainly outside North America and Japan, that use the 2-mega- 
bit-per-second primary rate interface and the CCITT (International Telephone and Telegraph Consultative Com- 
mittee) R2 or Number 7 signaling systems. Peripheral units connected to the network collect and preprocess 
data on various network parameters and transmit their measurements to a central computer, which elaborates 
the data and provides the user interface. The parameters measured, some of which are specified by the CCITT. 
are related to traffic intensity and type, the quality of service, and network efficiency and use. 

December is our annual index issue. You'll find the 1991 index on page 69. 

R.P. Dolan 
Editor 



Cover 

An artist's rendition of a typical HP Sockets domain (a less artistic rendition is given in Fig. 1 on page 6). The 
cable-like strand going through the center of the spiral represents a LAN and the panels connected to the 
strand represent diverse applications that are communicating with each other via HP Software Integration 
Sockets. 



What's Ahead 

The February issue will have several articles on the design of the HP 54600 digitizing oscilloscopes, These are 
100-MHz oscilloscopes that have the rapid display update rate characteristic of analog oscilloscopes along 
with the data storage advantages of digital oscilloscopes. The HP LanProbe monitors and HP ProbeView soft- 
ware for distributed monitoring of local area networks will be described in another article. A tutorial paper on 
neural networks will present the basic concepts of these computing architectures. 
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HP Software Integration Sockets: A 
Tool for Linking Islands of Automation 



The task of integrating diverse applications over a network of HP and 
non-HP machines is made easier with this software tool. 

by Mitchell J. Amino, Cynthia Givens, Mark Ikemoto, Alan C. Miranda, Scott A. Gulland, 
Kathleen A. Fulton, and Irene S. Smith 



IIP Software Integration Sockels (HP Sockets) is a soft- 
ware tool that enables efficient and reliable integration of 
new and existing software applications in a network of 
different computer systems and diverse applications. HP 
Sockets is designed to help system integrators overcome 
problems that are common in software integration and 
difficult to solve. HP Sockets provides a comprehensive 
set of communication features that are both broad and 
deep. It is intended to fulfill the needs of interapplk alion 
communications for file and message transfer. Messaging 
functionality is particularly extensive for both random and 
sequential, synchronous and asynchronous, destructive 
and nondestructive data transfers. Communicating pro- 
cesses can be written without regard lo language, com- 
puter type, or network topology. The same methods of 
communication can be used for either local or remote 
communication in a homogeneous (same machines and 
operating systems) or heterogeneous (different machines 
and operating systems) environment. Fig. 1 shows some 
typical applications that could be integrated with IIP 
Sockets. 

HP Sockets runs on HP 9000 Series 300, 400, 700, and 
800 computers running the HP-l'X* operating system, and 
HP 3000 Series 900 computers running the MPE XL oper- 
ating system. Sockets can also communicate with non-HP 
systems (see "HP Sockets Gateway" on page 20). 

After a brief overview, this article will describe the opera- 
tion and implementation of the major components of IIP 
Sockets. 

Overview 

Using HP Sockets, a system integrator can shorten the 
system integration time by up to 75%. HP Sockets helps 
shield system integrators from all the vagaries of network 
interfaces and differences in hardware and system soft- 
ware. HP Sockets also helps resolve data incompatibilities 
between communicating applications. For end users, HP 
Sockets offers flexibility in the management of an inte- 
grated system. System configuration can be easily 
changed because HP Sockets supports incremental inte- 
gration so that new hardware or software can be added 
without modification of the existing links. 

The major problems involved in integrating new and ex- 
isting software applications result from the differences in 
hardware platforms and their associated operating sys- 
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Fig. 1. Examples of the type of applications might be integrated 
in the 111' Sockets domain. 

Lems. and differences in the applications themselves. Spe- 
cifically, these integration problems include: 

Differences in hardware platforms and operating sys- 
tems. Because computers are built on diverse hardware 
architectures and operating systems, data from applica- 
tions running on one system is often not usable on anoth- 
er system. 

Diverse network services. Programmers must change 
application code to create interfaces to different sets of 
network services. 

Incompatible data lypes. Different applicalions use differ- 
ent dala types according to their specific needs. Program- 
mers must write code to convert the dala from a sending 
application into types that a receiving application can 
use. 

Differences in data structures. Incompatible data Struc- 
tures exist because applications group data elements in 
various ways. For example, an element with a common 
definition may be stored in two different ways: applica- 
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Administration Components. The administration components 
include: 

IIP Sockets Manager. The IIP Sockets manager lets the 
user validate configurations, Star! Up and sliui down the 
HP Sockets system, use lire comniand processor, and 
peiiomi other IIP Sockets management functions. 
Command Processor. The command processor allows 
interactive testing of the messages and links to any pro- 
cess williin the UP Sockets domain. An I IP Sockets do- 
main is an environment consisting of all the nodes lhat 
are integrated via HP Sockets. 

HP Sockets Management Daemon (SMI)). This process 
assists the HP Sockets manager in performing manage- 
ment tasks on local and remote nodes thai are pari of the 
HP Sockets domain. 

Configuration Files. The configuration files are user- 
created files containing information about the IIP Sockets 
domain. At the Startup of this domain, information in 
these configuration files is used to build the memory-resi- 
dent configuration (ahles for the run-lime pari of III' 
Sockets (see "Configuration Files" on page bi). 

System Integrators 

As a software tool for system integration. IIP Sockets is 
not a stand-alone solution. HP Sockets is one of many 
components that make up an integrated system. The par- 
ticipating applications play a major patt; IIP Sockets pro- 
vides a foundation for the links between these applica- 
tions, but these links have to be built by system 
integrators. The tasks the system integrator must perforin 
to integrate applications with IIP Sockets include: 
System analysis. The system integrator must determine 
the system functional requirements, analyze data Hows 
between applications, determine data formats of the data 
flows, and define (he characteristics of each link. 



• System design. By determining the functional require- 
ments and by analy/.ing the data Hows and data formats, 
the system integrator will be able lo design the bridges 
between the applications and HP Sockets — iii other 
words, design the application adapters. 

• Configuration. After building ihe application adapters, the 
next task for Ihe system integrator is to configure the 
integrated system. Configuration means describing to HP 
Sockets the network topology, ihe participating pro- 
cesses, and the dala formals and dala manipulations lhat 
HP. Sockets will need lo perform for each link when it 
transfers data between cornmuniCating applications. 

Run-Time Architecture 

The IIP Sockets run-lime architecture is designed lo pro- 
vide the besl performance possible while using minimal 
system resources. IIP Sockets builds ils run-lime modules 
and activates them across ihe network without requiring 
user intervention. 

Two main components make up ihe IIP Sockets run-time 
architecture: the data transporter and the data rnanipuia- 
tion module. F.ach component is implemented as one or 
more programs and consists of several modules (see Fig. 
4). The archil eel lire shown in Fig. 4 exists on every node 
integrated via IIP Sockets. 

Data Manipulation Module. On the sending node this mod- 
ule performs two operations: il manipulates outgoing dala 
into a formal acceptable lo Ihe receiving application and 
il encodes Ihe data inio a common data representation. 
The encoding operation is called iii<trslt<iliii<i and the 
common dala representation is a language and machine 
independent data Format The incoming network manager 
on Ihe receiving machine unmarshals Ihe data (i.e., con- 
verts il to local machine and language representation). 
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For more about marshaling, common data representation, 
and data manipulation, see "Data Manipulation" on page 

20. 

Request Manager. This module routes application adapter 
requests through the internal HP Sockets modules to the 
request's eventual destination. The data messages it re- 
ceives from the incoming network manager are stored 
until an application adapter issues a read request. The 
request manager handles only requests and leaves the 
data manipulation and file transfer tasks to other mod- 
ules. Requests include message transfers, file transfers, 
and local or remote program control. 

Outgoing Network Manager. This module sends messages 
over the network. Ii communicates with the incoming 
network managers on the other nodes. It creates and 
holds communication open to other nodes as required. 
Resource use is minimized because this module is shared 
by all the processes on a node, and it can clone itself as 
resources are needed. 

Incoming Network Manager. This module receives messages 
from the outgoing network managers on other nodes. 
When it receives data it converts (unmarshals) the data 
from the common data representation that is used across 
the network into its hosl node's local representation. The 
data is passed to Ihe local request manager for delivery. 
To optimize resource use, Ihe incoming network manager 
also clones itself to meet its needs. 

File Handling Module. This module transfers files between 
nodes. A process can request a file to be transferred and 
a notification to be sent to the request manager on the 
receiving node when Ihe file arrives. 

The error logger and Ihe run-time configuration lables 
shown in Fig. 4 are used by both the dala Iransporter 
modules and Ihe dala manipulation module. The error 
logger logs any errors or notable events (e.g., startups, 
shutdowns, etc.) detected during run-time operation. Ac- 
cess routines are provided so that the user can log user- 
defined messages using the error logger. 

The run time configuration tables contain dala that HP 
Sockets extracts from the configuration files for run-time 
operation, such as node names and dala manipulations. 

Run Time Operation 

The run-lime operation of HP Sockets on a sending node 
typically begins with the request manager receiving re- 
quests front an application adapter to perform a specific 
task such as to send a message or file, or to retrieve a 
message. Pig. 4 shows the data flows during these opera- 
tions. If the request manager receives a request to send a 
message that is destined for a remote node and the mes- 
sage does not have to be manipulated, the message is 
sent directly to the outgoing network manager. When a 
message has to be manipulated, the request manager 
sends the message to Ihe data manipulation module. After 
manipulating the message, the data manipulation module 
sends Ihe message to the outgoing network manager. If 
the request manager receives a request to send a file, it 
notifies ihe file handling module, which sends Ihe file and 
I hen sends a file notification message to the outgoing 
network manager. The outgoing network manager for- 



wards the file message to the incoming network manager 
on the remote node. 

On the remote node the incoming network manager sends 
the message to its request manager. If the file message 
has file notification turned on. the request manager sends 
a signal notifying the receiving application that a file has 
been sent to it. If file notification is not turned on, the 
application is not notified about the file sent to it Status 
messages indicating success or failure of a request are 
returned to the sending application adapter when a re- 
quest is made with wait. 

Startup and shutdown are synchronized between the run- 
time modules. After the run-time modules are started, 
they perform initialization. All modules complete initializa- 
tion and wait before they are allowed to process data so 
that if one module fails to initialize, startup can be 
aborted. Also, modules have some interdependencies that 
need to be resolved before data processing begins. For 
example, since modules rely on each Others 1 system mes- 
sage facilities such as message queues, these facilities 
must be created by each module before data processing 
can begin. The IIP Sockets management daemon is the 
process that notifies modules to start processing data. At 
shutdown, the IIP Sockets management daemon notifies 
all modules to shut down. To prevent loss of messages in 
transit between modules, modules perform a graceful 
shutdown by sending last messages to the appropriate 
modules before terminating. The HP Sockets startup and 
shutdown functions are described in more detail later in 
this article. 

Adapters and Access Routines 

To link existing applications without requiring them to 
change, a bridge is needed between an application and 
IIP Sockets. That bridge is called an application adapter 
(see Fig. 5). An adapter is usually a program, but it could 
be a procedure if the application is capable of calling 
user-written routines. 

Application adapters are created with the access routines 
supplied by IIP Sockets. This programmatic interface con- 
sists of IIP Sockets routines callable from C, FORTRAN. 
COBOL, or Pascal programs to send messages, copy files, 
control processes, and so on. Any program or procedure 
thai uses an HP Sockets access routine is, in effect, an 
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application adapter. The user determines how an applica- 
tion adapicr is implemented. 

There are I wo main functions in an adapter data access 

and interfacing. 
< Data Access. The rlata access function retrieves data 

from the application or delivers data lo I he application. 

Data access can be as simple as reading an application 

data file or accessing tlte application's data base. 
1 Interfacing. This means using IIP Sockets access routines 

to Iransmil data between applications, or asking IIP 

Sockets hi slail or slop another process. 

Once the scope of the adapter is determined, the features 
uf IIP Sockets need to be factored into the design. The 
adapter will use these features through the ill' Sockets 
access routines given in Table I. These routines are the 
door through which the HP Sockets world is entered. 
They are easy to leant, consisting of only 12 procedures 
which completely shield the interface developer from the 
network services levels. All functionality is expressed in 
functional terms such as read message, send message, 
send files, and so on. Sophisticated interfaces can be 
Written with minimal programming. 

IIP Sockets provides a way to exercise these access rou- 
tines interactively. This is done using the HI' Sockets 
command processor. Tlte command processor is a pro- 
gram (hal has a set of line mode commands thai allow 
the user lo simulate an adapter using access routines, 
(incc IIP Sockets has completed startup, with the com- 
mand processor the user can read or send messages or 
files, and start or stop a user process. Data can be sent 
or displayed in either ASCII or binary. 

The command processor can be used to test newly im- 
plemented adapters. Fig. 6 shows art example configura- 
lion consisting of two adapters, adapter 1 and adapter 2. 
Adapter 1 sends messages to adapter 2. If adapter 2 does 
not receive the message sent from adapter 1 the error 
can be found as follows: 
Test 1 

Shut down adapter 1 and set up the command processor 
to simulate adapter I. 
: Using the command processor, send a message to adapter 
2 using the same formal its would be sent by adapter 1. If 
adapter 2 receives Lite message correctly, then the defect 
is in adapter L. If adapter 2 does not receive the message 
or receives an incorrect message the defect may be in the 
configuration or adapter 2. 
Proceed to lest 2. 
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• Test 2 

Shut down adapter 2 and set up the command processor 
to simulate adapter 2. 

Start up adapter 1 and receive the message with the com- 
mand processor. If the command processor can receive 
the message correctly from adapter 1, the the defect is in 
adapter 2. 

Table I 

HP Sockets Access Routines 
Access Routine Description 

These routines control adapters. 



Splnit 



SpEnd 



SpStartProcess 



SpStopProcess 



SpErrLog 



SpError 



Initiate communication between III' 
Sockets and a calling process. 

End communication and clean up 
resources allocated for the calling 
process by HP Sockets. 

Start an HP Sockets configured 
user process. 

Stop an HP Sockets configured user 
process. 

Log a user error message in the HP 
Sockets error logfile. (Send applica- 
tion-specific messages lo the HP 
Sockets error logger.) 

Retrieve ASCII messages corre- 
sponding If) the HP Sockets error 
codes returned bv routines. 



These routines control data transfer belween appli- 
cations. 



SpSendMsg 



SpSendFile 



SpControl 



SpReadQ 



SpFlush 



SpDelGuaranteedMsg 



Send a message to a local or remote 
process. 

Copy a file to a destination file on a 
local or remote node. 

Control the HP Sockets access rou- 
tine options (such as timeout or 
message notification) that are avail- 
able to the calling program. 

Read messages from the incoming 
message queue for the process. 

Flush pending requests and clear 
the timeout list for the process. Use 
this only when doing a longimp out of 
an interrupt routine. 

Remove a guaranteed message 
from the guaranteed message spool 
file. 



Test Connections 

Fig. 6. Testing application adapters. 



Data Transport 

Data communication between an application and HP 
Sockets starts with the application adapter making a call 
to the the access routine Splnit to initiate communications 
with HP Sockets (see Fig. 7). This call sets up message 
transfer facilities (message queues for HP-UX and mes- 
sage files for MPE XI.) for data and status messages be- 
tween the application adapter and the request manager 
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and generates an initialize request to the request manager. 
The initialize request contains information such as the 
calling adapter's logical name, its process identification, 
and its newly created message queue identifier. The re- 
quest manager enables the communication links for the 
calling process (whose name is already stored in the run- 
time configuration table i and returns a status message 
telling whether the Splnfl call was successful. Once a pro- 
<-esss communication link is enabled with a successful 
Splnit call. It can make calls to any of the other HP Sock- 
ets access routines. 

The HP Sockets access routines handle all data transport 
between an application and the HP Sockets system. The 
main routines used for data transport are SpSendFile. 
SpSendMsg, and SpReadQ (see Tahle 1). All access routines 
communicate between their calling program and the re- 
quest manager, whose main function is to receive re- 
quests and route them between other internal modules, 
and between local and remote application adapters. As an 
example. I lie application adapter on I he sending node 
initiates a call lo SpSendMsg, sending: 
A data buffer 

A destination process logical name (on a remote node) 
An optional link logical name which indicates that data 
manipulation must be done before data goes to the outgo- 
ing network manager 

A no-flags-set parameter, which indicates send with wait. 

After some preliminary error checking, Ihe SpSendMsg pa- 
rameters are pul into the HP Sockets standard message 
structure and the message is sent lo Ihe requesl manager. 
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(Initiate 
Communication) 



File 
Sending 
Request 




Status or Message 

Irom Incoming 
Network Manager 



o-» Data 
•-»- Status 



To Data Manipulation 
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Network Manager 



Fig, 7. Structure chart showing the coramunieeUon (tola (low* be- 
tween tin' request manager anil sunn- ol tin- III 1 Sockets access rou- 
tines. 



Since the routine was called with wait, the SpSendMsg call 
will not return lo the calling routine until it either re- 
ceives a status vaflK back from the request manager or 
times out. 

When the request manager receives the message from 
SpSendMsg. it validates the destination process logical 
name against the data in Ihe run-time configuration table, 
;uul iheii checks to see if the destlnaUon process is con- 
figured to be on a remote node. If this is the case. Ihe 
request manager sentls a message to the outgoing net- 
work manager to set up communication with Ihe node if 
it is not already done. Next, the logical link name is ex- 
amined. If it is nou-NULL a message is sent to the data 
manipulation module, where the data is massaged accord- 
ing to the manipulations associated with thai link name. 
After the manipulalions are done, the message is encoded 
into Ihe common data representation format and sent lo 
Ihe outgoing network manager for transfer to the remote 
node. If a link name had noi been specified (i.e.. a NULL 
link name), the message is sent directly from Ihe request 
manager to (he outgoing network manager, bypassing Ihe 
data manipulation module completely. 

When the requesl manager on Ihe remote node receives a 
message (via the incoming network manager I. ii stores 
Ihe message in its memory area. When Ihe message is 
successfully stored, a reluni message containing ihe sta- 
tus of the transfer is sen! back to the original ing (local) 
node via the remote node's outgoing network manager. 
The local incoming network manager receives the return 
message, tinmarslials it. and passes it lo the local requesl 
manager. The local requesl manager sends it back to the 
adapler lltal originated the access routine call, completing 
the wilh-wail SpSendMsg call. 

Once a data message arrives for a process on the destina- 
tion node, Ihe message is not senl to the destination 
adapier until the data is explicitly requested by a call i<» 

SpReadQ from Ihe destination adapler. I'nlil Ihal call is 
made, dala messages for all local processes are slored in 
an area of shared memory called the shared memory mes- 
sage area (an exceplion is guaranteed messages, which 

are described later). 

The destination adapler has two ways of finding out if il 
has a dala message wailing: polling and iniemipl nolillca 
lion. Polling involves continually making calls lo SpReadQ 
in sec if I here is a message. There can be a user-specified 
timeout for each of these calls. If a large enough liineoul 
is specified. Ihe adapler will block unlil a message arrives 
for ft Irtterrupl notification involves turning on the data 
or file notification feature of HP Sockets. When Hinted 
on, a notification ( via a signal from HP-UX) is sent to the 
destination adapter when a dala message or file arrives 
for lhal adapter. This feature is set up by the destination 
adapter through Ihe use of the SpControl access routine. 
The adapler original ing a SpSendFile or SpSendMsg call does 
not know whether Ihe destination Adapter has set up noii- 
ficalioit. 

The SpReadQ message is senl to the requesl manager, 
which scans ils memory area lo find data messages asso- 
ciated wilh the calling adapter. If Ihe coitccI dala mes- 
sage is found (particular messages can be requested, using 
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the SpReadQ lag parameters, or by specifying Ihe logical 
name of the sending process whose message the receiving 
process wishes to read), it is removed from the shared 
memory message area and sent to the calling adapter. 

If an incoming message needs to be put into the shared 
memory area, and either the whole memory area has 
been filled or the user-configurable percent allocation for 
a single process has been reached, the message is written 
to a special overflow spool file. This file will hold all sub- 
sequent messages for that process until space is freed in 
the shared memory message area by calls to SpReadQ. 
Anytime a successful SpReadQ is done for a process that 
has overflow messages, the overflow messages are read 
from the file into the shared memory area. This is done 
until the memory area limit is reached again or until the 
overflow spool file is emptied. 

When the SpSendMsg access routine is called, a flag called 
the guaranteed flag can be set. Setting this Hag tells the 
destination request manager to write the data message to 
a disk file rather than put it into the shared memory mes- 
sage area The SpReadQ call done by the destination pro- 
cess must likewise set this flag so that the disk file is 
searched for the data message rather than the memory 
area. It is slower to send and receive a guaranteed mes- 
sage than a nonguaranteed message because of the over- 
head of disk access. However, the benefit of a guaranteed 
message is that the data will not be lost if a power fail- 
ure occurs. The shared memory message area cannot be 
recovered after a power failure. 

Guaranteed messages can be deleted using an option in 
SpReadQ, but to be absolutely sure that the data has been 
received the data should first be read with a Hag indicat- 
ing that the message is not to be removed from the disk 
file (using the no-consume flag), then as a separate step a 
call should be made to the SpDelGuaranteedMsg access rou- 
tine to delete the message. A drawback of guaranteed 
messages is that they can only be read in the order they 
were received by the request manager; they cannot be 
retrieved by their tag values, or by specifying Ihe logical 
name of the sending process. 

Network Interface 

The outgoing network manager and the incoming network 
manager are the modules within HP Sockets responsible 
for transferring messages across the network. Optimum 
performance is the reason network input and output tasks 
are divided between these two modules. 

The incoming and outgoing network managers currently 
use NetlPC' 1 intrinsics to interface with the network pro- 
tocols. ( BSD sockets can be used by HP-UX nodes run- 
ning HP Sockets provided that there are no MPE XL 
nodes in the HP Sockets domain. MPE XL does not cur- 
rently support BSD sockets.) With NetlPC. communication 
between the incoming and outgoing network managers 
involves establishing a \irtual circuit connection, which is 
referred to as a virtual circuit socket descriptor. Multiple 
socket descriptors are needed for communication be- 
tween multiple nodes. Socket descriptors are allocated 
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Fig. 8. Outgoing and incoming network manager processes and their 
connections. 

from the same space as file descriptors. A process is lim- 
ited to a certain number of file and socket descriptors 
that it can have open at any given time. The design of 
the outgoing network manager and incoming network 
manager allows HP Sockets to communicate with several 
nodes at a time by having the two network managers' 
parent modules (Onmp, Inmp) fork child processes (Onmc, 
Inmc) as needed to establish and hold connections (see 
Fig. 8). 

When an Onmc or an Inmc reaches its maximum number of 
connections, another Onmc or Inmc process is created. The 
parents manage the children and do not hold any connec- 
tions themselves. 

When the request manager needs to send a message to a 
particular node for the first time, it notifies the Onmp, 
which in turn assigns an Onmc process the responsibility 
for communicating with that node. After the Onmc process 
successfully establishes a connection with the remote 
Inmc, they exchange a message to ensure that the HP 
Sockets configuration is a compatible version on both 
nodes. If the versions are not compatible, communication 
is terminated. Otherwise, the Onmc process can send mes- 
sages it receives from local processes to the Inmc on the 
destination node. After receiving a message, the Inmc un- 
marshals the message and sends it to the local request 
manager, which is responsible for routing the message to 
the end application. 

If an Onmc fails to establish or maintain communication 
with a node for any reason, such as a node or network 
failure, it spools to disk all messages that the sending 
application specifies as critical and that are destined for 
the node associated with the failure. 



Icominued on page 141 
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Configuration Files 



Configuring an HP Sockets system requires the user to create six configuration 
files These six files, which can be created with any text editor, describe to HP 
Sockets m complete detail the HP Sockets operating environment with information 
such as the participating nodes, the communicating processes, and the data to be 
transported Rg 1 shows the sot configuration files and the specific items erf infor- 
mation that associate each file with the other files These files can be treated m 
any order using the information gathered in the system analysis phase. Only the 
first two files, NETWDEF and PROCDEF are required to describe an HP Sockets 
domain 

Network Definition File i NETWDEF). The NETWDEF file identifies the nodes 
Icomputer systems) in the HP Sockets domain, giving their logical and physical 
names, hardware types, startup status, and C compiler availability Isee fig. 2). 
Nodes are identified by their physical LAN name and are given a logical name 
(e g., cpul in fig. 2) All references to a node are done with the logical name so 
that if a node is removed, all HP Sockets functionality can be transferred to anoth- 
er name with just a change m the NETWDEF file. The startup status says whether 
or not a node should be started up 

Process Definition File IPROCDEF) The PROCDEF file lists all processes known 
to the HP Sockets domain (see Fig 3). This file also ties a process to a logical node 
name (e.g.. in Fig 3 process lookupep is tied to node cpul I When the user speci- 
fies the movement of data in the system, the receiving process name is used, not 
the node name The correct node is identified using the PROCDEF data. For pro- 
cesses listed in this file that are to be started or stopped using HP Sockets, the 
user can specify a run string with parameters in the PROCDEF file Also, execution 
information such as the user identifier and password can be kept in this file 

File Definition File IFILEDEF) The FILEDEF file lists any attributes of files that will 
be transferred using HP Sockets. This file is optional File attributes refer to the 
receiving node, and define such things as type (ASCII or binary), record size, and if 
the existing file can be replaced Files that are not specified in this file can be 
moved using HP Sockets, provided the default file attributes used by HP Sockets 
are acceptable 

Data Definition File (DATADEF) This file defines the structure of the data trans- 
ported between processes or applications. This file is optional 

Data Manipulation Definition File (DMANOEFI This file defines the manipula- 
tions that must be performed on the data to make it understandable to the receiv- 
ing application This file is also optional 




Fig. I, HP Sockets configuration files and the fields in each file that associate one lile with 
another . 



•The Network Definition file. NETWDEF. most contain an entry lor each node in the HP 

■Sockets domain 

f 

■This is the format lor each entry The numben m parentheses indicate the maximum 

ttenglh ol each lield Optional items are enclosed in square brackets 

• 

•Node a logicalNoocName Machine Type 

* 116) I16J 
stStamip = SurtupStafus! 

« (II 

iCompilationNode ■ CoDipilalionNodeRagJ 

* 111 
■[MaxClones = MaxCIonesNumber] 
• 

■fMaxMessageArea = MaxMsgAreaSire) 
I 

•IMaxPcrProcess = MaxMsgAreaProcess] 

« 131 

■NetwofkType = Networking Type ! PhysicalNodcName 

* 1501 
Node • cpul HP90O0/S8OO 

Startup = I 

CompilationNode ■ 1 

MaxClones ■ 0 

MaxMessagesArea ■ 100 

MexPerProcess = 50 

NelworkType = LAN : hpiaclg tip.com 

I Use Ihe nodename command Irom the shell lo gel this name 

f 

This is Ihe end ol the node definitions. 

Fig. Z A portion of a network definition file (NETWDEFI 

Link Definition File ILINKDEFI. This file ties the data manipulations In the 
DMANDEF file and the data definitions m the DATADEF file to the sending architec- 
ture, and to the sending and receiving languages. The same manipulation defini- 
tion can be used in links describing differing languages and source system types 
This modular approach to data movement allows the user to specify more easily 
many different types of links by leveraging from a single user message representa- 
tion This file is optional 

Link definitions are used to describe a specific link (data transfer) between two 
applications Each link defines the language used by the source application to 
produce the data and the language that is used by the consuming application to 
access the data Each link must also describe the format of the data at the sending 
and receiving ends of the link and any data manipulation that should be applied to 
the data 

In essence, a link definition name is used to bind the physical characteristics and 
operations that must be performed on data being transferred between two appli- 
cations. This link name is used by the sending application at run time to invoke the 
operations necessary to get the data into a format usable by the receiving applica- 



■The Process Definition file. PROCDEF. musl contain an enliy lor each process known lo Ihe 
■HPSockcls Domain. 

■This is Ihe lotmal lor each enliy. The numbers in parentheses indicate Ihe maximum 

■length ot each field Optional items are enclosed in square brackets. 

| 

■PIN = ProcessLogic Name UgicalNodeName t:CloneFlag] 

• (16) 1161 (II 

•(Exec ■ Execlnlol 

« 11281 

XRun = DelaullRunSlnng] 

» I2S5) 

PIN = lookupep ' cpul i 0 

Exec = 100 user : passwd 

Run = youi home directory/lulonal/progtams/lookupcp 
• 

PIN = inqcp : cpul :0 
Exec = 100 user : passwd 

Run = youi home direclory/lutonal/piograms/inqcp 
• 

■inqcp is tho end ol Ihe process definitions. 



Fig. 3. A portion nf a process definition tile IPROCDEF) 
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Fig. 4. 1 I'b configuration validation process 

Hon At validation time, the link information is used to help generate the source 
code that carries out the operations at run time 

Examples of a data definition file, a data manipulation definition file, and a link 
definition file are provided in "Data Manipulation" on page 20. 

Changing Configuration 

Changing a configuration is a simple task performed via the HP Sockets manager 
A configuration is changed to add nodes Icompuiers) to the domain or remove 
them from it, ot to alter definitions, processes, manipulations, 01 links The steps 
required to change to a new configuration include 

• Modifying the configuration files This can be done while HP Sockets is running a 
current configuration 

• Validating the new configuration files This can be done while HP Sockets is run- 
ning a current configuration. 

• Shutting down HP Sockets when validation is successfully completed. 

• Starting HP Sockets with the new configuration. 

Configuration Validation 

Before the configuration files can be used by the HP Sockets run-time modules 
they must be checked against one another for correctness, and the files containing 
the data definition and data manipulation definition data must be compiled The 
process to get all this done is known as configuration validation |see Fig 4) Con- 
figuration validation takes place on the administration node and includes the 
following activities. 

• The validation program reads the network definition (NETWDEFI, process definition 
(PROCDEFI. and file definition (FILEDEF) configuration files from the user's directory 

• Die validation program invokes the DDL (data definition language) and DML (data 
manipulation language) compilers, which read the OATAOEF and DMANDEF files 
respectively The DML compiler also reads the link definitions from the LINKDEF 
file. 

• Code generation takes place in two phases The first phase generates the code to 
perform data manipulations and occurs as each data manipulation is recognised 
The second phase occurs after all of the data manipulation definitions have been 
processed and is responsible lor generating the data manipulation C source files 

• The validation program generates a catalog file which contains information about 
the files used for the latest validation 

The validated configuration files are in a format that can be loaded intD memory to 
became the memory-resident configuration tables 

For the code generation process described above, one area ot great concern is the 
ability to add support quickly for new languages and computer architectures To 
aid this goal, the code generator has been designed to be table-driven Two princi- 
pal types of tables are used The first type describes the physical representation of 
the data types for a specific language on a specific architecture and the second is 
used to describe legal type conversions between data types and the functions to 
call to generate the code to perform the type conversions 



If communication fails because of a connection failure, 
the Onmc process notifies its child process Onmh (outgoing 
network manager helper) to begin tryi»8 to detect when 
it is possible to communicate with the node again. The 



Onmh, in turn, notifies the Onmc when In try to communi- 
cate With the node again. The Onmc sends the spooled 
messages when the cause of the network service failure 
disappears and the Onmc can successfully establish a con- 
ned ion lo the node. 

The Onmc spools messages destined for different nodes lo 
the same spool file, rather than maintaining a spool file 
for each node. This is done primarily to save file descrip- 
lors lor connections. The spool file is segmented into file 
blocks. A file block is associated with a node and all file 
blocks belonging lo one node are linked together. Mes- 
sages, including spooled messages, are always sent to a 
node in the same order in which they are received, 

IIP Sockets Management Daemon 

The management of HP Sockets across various nodes 
linked by a 1.AN requires the existence of a daemon pro- 
cess on every node, which is responsible for performing 
the various management tasks on that node. This daemon 
is called the HP Sockets management daemon, or S.MD. 
The allribut.es of the SMD include: 

• Providing support lor the 111' Sockets functions on a node 
in the HP Sockets domain 

• Remembering the steps of any task performed so I hut 
they COT be undone if requested or if the network connec- 
tion to the requester is lost 

• Supportinga wide variety of requests from I he III' Sock- 
ets manager (smain) on any node 

• Providing extensiblity for future requirements 

• Supporting requests from various nodes simullaneously. 

The HP Sockets managemenl daemon, as its name im- 
plies, is designed to run in the background and disassoci- 
ate ilself from the login session. It uses a slighl variation 
of the approach suggested in reference 2. 

The SMD is also responsible for scheduling I he HP Sock- 
els programs on I he local node. For example, in the HP- 
UX environment some of the programs need lo be sched- 
uled as the HP Sockets user (hpskts) wliile others need to 
be scheduled as the root user. To accomplish Ibis Ihe SMD 
is itself scheduled as root. II then switches itself to being 
an hpskts user. This sets its real-user identifier and its ef- 
feclive-user identifier lo hpskts and ils saved-user identifier 
to root. So now the SMD can switch itself between an 
effective-user Identifier of root and an effective-user identi- 
fier of hpskts as needed. 

When the SMD is scheduled it also starts Ihe error logger 
program and the file transfer daemon. II monitors diese 
programs because they are critical lo the operation of HP 
Sockets on that node. If either program fails then the 
SMD stops all aciivity on the node and shuts itself down. 
The SMD always keeps track of the GUTrent status of the 
node by saving status information in an internal variable 
called NodeState. This information can then be made avail- 
able lo any HP Sockets program that requests it. 

Some of the requests that the SMD supports are mutually 
exclusive (e.g., Ihe HP Sockets manager functions startup, 
shutdown, and switchadmin ). Such requests are called major 
requests. Other requests like nodestat can be made at any- 
time on any node. To control the major requests on the 
node, the SMD maintains an internal flag called the Maior- 
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RequeslFlag. When an IIP Sockets program wants to ex- 
ecute a major request, it first attempts to set this flag 
before proceeding with the request itself. Information 
about the major request currently being executed on the 
node is stored in a separate global variable called MajorRe- 
quest. The MajorRequest variable also keeps track of the 
connection on which this request is made. The S.\ID uses 
this connection and other factors to identify who has con- 
trol of die MaiorRequestFlag. 

The SMD's primary task is to handle local or remote re- 
quests from the IIP Sockets manager (see below), The 
SMD sets up a network call socket on which it can re- 
ceive a connection request from the IIP Sockets manager. 
After accepting the connection request, the SMD creates a 
virtual connection to the HP Sockets manager. This con- 
nection is left open until the HP Sockets manager decides 
to shut it dOWtt. If the connection is lost for any reason 
then the SMD reverses the steps taken during the request 
and clears the MaiorRequestFlag (if it was set by the HP 
Sockets manager on the lost connection). 

Once a connection has been established to the IIP Sock- 
ets manager, the SMD processes the requests sent by the 
HP Sockets manager. The reply to the request will depend 
on the request itself and the success or failure of the 
SMD in executing the request. To facilitate the communi- 
cation, the SMD has a well-defined message buffer that it 
transmits across the network. This buffer is used by all 
IIP Sockets programs that want to communicate with the 
SMD. 

Another function of the SMD is to help expedite Certain 
requests, especially the startup of nodes across the IAN. 
One way is to have the SMD copy (i.e., pull) the files 
required by its node rather than have them copied (i.e., 
pushed) by the HP Sockets manager. This approach also 
gets around the need for the IIP Sockets manager to have 
special permissions lo do the push. 

Fig. 9 shows a simplified illustration of the connections 
between (he IIP Sockets manager and its local SMD and 
some remote SMDs. 

HP Sockets Manager 

The IIP Sockets manager program (smain) is the main 
administration component of IIP Sockets. It can be run 
from any node in the IIP Sockets domain. The IIP Sock- 
ets manager is used by the system integrator for creating 
an integrated system and by the system administrator to 
manage the integrated system. The IIP Sockets manager 
uses passwords lo guard against unauthorized access. 

The primary lasks that can be performed by a system 
administrator through the IIP Sockets manager commands 
are: 

Starting up and shutting down the system from the ad- 
ministration node 

Establishing a security scheme for the system from the 
administration node 

Responding to errors recorded in the error log file by HP 
Sockets from any node 

Customizing the error log files to meet system needs from 
any node 

< 'becking stains of the IIP Sockets domain from any node 



Local Node 



Remote Node 




SMD= HP Sockets Management 
Daemon 



Fig. 9. < ■iiiiiii-ctioits lietwiveen thr HP Swki'is rnanagiT and its lural 

SMD and remote SMI k. The message buffer contains status and re- 
quest dnta. 

| Switching administration capability from one node to 
another front an administration or alternate administra- 
tion node 

1 ( hanging HP Sockets parameter values from the adminis- 
tration node only. 

Switch Administration Tin- switch administration (switchad- 
mm) function of the IIP Sockets manager was created so 
thai the major IIP Sockets administration functions would 
not be lost if the administration node is unavailable. 
There can only be one administration node in an IIP 
Sockets domain of nodes. However, any of the Other 
nodes may be designated to be alternate administration 
nodes. Alternate administration nodes are the nodes In 
the HP Sockets domain thai are able to lake on the title 
and functions of the administration node. This is done 
using the switchadmin function on the alternate administra- 
tion node. 

When the user invokes the switchadmin function, the local 
IIP Sockets management daemon (SMD) is contacted for 
status information. The SMD returns status about the lo- 
cal node, and a check is done lo sec whether the node 
requesting the switchadmin is an alternate administration 
node. 

The switchadmin first tries to make a network connection 
with the SMD on the current administration node. Il then 
sends a message to that SMD telling it to switch itself 
from an administration to an alternate adminisi rat ion 
node. This switch involves updating internal variables in 
the SMD that contain lite adminisi ration status, and the 
logical and physical names of the new adminisi ration 
node. Next, the switchadmin module connects to ils local 
SMI), sending a message telling it lo switch itself to an 
administration node. This also involves updating the same 
SMI) internal variables. Finally, after the old and new 
administration nodes are in synchronization, a list is 
created containing all (he other nodes configured in the 
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current IIP Sockets system. Connections arc made to the 
SMDs on these nodes, and messages are sent informing 
these SMDs of the new administration node's logical and 
physical names. 

If one or more nodes are down when a switchadmin is 
done, they can be resynchroni/.ed later by rerunning the 
switchadmin function from the administration node. 

Node Status. The HP Sockets manager node status func- 
tion (nodestat) gives information on one or all of the nodes 
configured in the current HP Sockets domain, or in anoth- 
er as yet (installed domain whose configuration files are 
in a user-specified directory. 

Nodestat makes a connection with the SMD on each node 
from which it is obtaining status information. The SMD 
on each node retrieves the status information from its 
internal variables, and sends it back to the requesting 
process. Typing nodestat at the IIP Sockets manager 
prompt will give information about the local node, and 
typing nodestat <node logical name> gives information about a 
particular node. Typing nodestat " will list Information 
about all nodes. 



'Die information shown for node status includes: 

• Logical name 

• Physical name 

• Run-time status (running or stopped) 

• Administration class (administration, alternate adminis- 
tration, or maladministration) 

• Machine type 

• Administration node logical name 

• Administration node physical name. 

Security. The III' Sockets manager security function al- 
lows the user to add and delete user names and pass- 
words that are required to access the IIP Sockets manag- 
er. The allowable commands for the security module are: 

• Add, Add a user name and password to the user file 

• Delete. Delete a user name and password from the user 
file 

• List. List all user names in the user file. 

The security file is disseminated to all the nodes in the 
domain at Startup and after each update. 



Performance in the HP Sockets Domain 



Since it is impossible to predict the performance ot HP Sockets for all possible 
configurations, some results are presented for several example test configurations. 
These tests represent typical configurations in which HP Sockets operates De- 
scriptions of factors contributing 10 performance results are also given 

Test Configuration 

The system factors affecting HP Sockets performance include the CPU type, oper- 
ating system, LAN activity, and network configuration Tests were performed 
between HP 9000 Series 300 and Series 800 computers connected by a LAN All 
systems used the HP-UX 7.0 operating system and contained 16 megabytes af 
main memory All tests were run on an isolated LAN link. Except for virtual memory 
daemons, no other system processes were running during test execution Fig 1 
shows three sending adapters and one destination adapter running on separate 
nodes All messages were directed to a single destination adapter and both nodes 
were sending and receiving messages concurrently through HP Sockets. The mes- 
sage transit lime between two adapters was estimated by measuring the time to 
transfer a large batch of messages (typically 5000 messagesl between each send- 
ing and destination adapter pair The message transit time was calculated as the 
time difference between the first send and the last receive, divided by the batch 
si?e File transfer time was measured using the same method Also, CPU utilization 
and the number of LAN packets going across the network were monitored while 
the tests were executing 

For the setup shown m Fig. 1 , each sending adapter sent messages as fast as it 
could The overall sending rate was increased by increasing the number of sending 
adapters For stress tests. 96 sending adapters were successfully tested 

Performance Results 

Some of the product-specific factors that affect the performance of HP Sockets 
are 

i The sending rate lin Fig. 1, the number of sending adapters) 

> Whether delivery is with wait or without wait 

i Whether delivery is guaranteed or not guaranteed 

' The size of the message or file 

i The data manipulation required for each message 

Message transfer times were studied for message sizes of 64, 256, 768. and 1024 
bytes. HP Socket's maximum message size is 1024 bytes. The maximum file size 
tested was one megabyte 
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fig. 1. Tesl configuration for perlormance tests. 

A sending adapter can deliver a message with or without wait. When delivering 
with wait, the sending adapter does not continue until it receives an acknowledg- 
ment from the destination node Therefore, the time for a round trip occurs be- 
tween each message sent In contrast, when a sending adapter delivers a batch of 
messages without wait, it can send messages at a higher rate. 

The Oiroughput is faster for a batch of messages delivered without wait In fact, if 
the systems are not heavily loaded, delivery without wait can double the through- 
put. If the systems are heavily loaded, the increase in throughput may not be 
noticeable 

Similarly, a sending adapter can deliver a message with or without guarantee. 
Messages delivered with guarantee are written and flushed to a disk file: thus two 
disc accesses la write followed by a readl are done for each guaranteed message 
transfer In contrast, messages delivered without guarantee are kept in shared 
memory Guaranteed message delivery requires more system resources (CPU and 
disk 1/0). However, the total message transit time may be unaffected, unless the 
systems have extremely high 1/0 activity, 
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Fig. I HP Sockets file transit time as a function of file size using an HP 9000 Series 370. 

Fig 2 shows the performance for file transfer between two HP 9000 Series 370 
computers File transfer time for a small file (less than 10 kilobytes) is about 600 
milliseconds. File transfer time increases with file size — from about 0.6 second for 
a 10-kilobyte file to about 4 seconds for a one-megabyte file 

Fig 3 shows the message transfer time as a function of message size Again two 
HP 9000 Series 370 computers were used The data in Fig 3 was generated for 
delivery without wait and without guarantee, but tests with wail and with guaran- 
tee showed results that were only slightly higher The line labeled "No Data Ma- 
nipulation" shows the results for messages sent without data manipulation Since 
these messages were transmitted directly to their destination, the transfer time 
was fast and showed little dependence on the message size. Even for the maxi- 
mum-sized messages, transfer time without data manipulation was always less 
than 22 milliseconds 

The line labeled "Host Data Converted" is for messages that required simple data 
manipulation. Message transfer lime increased with the message size to about 70 
milliseconds for large messages. The line labeled "Extensive Data Manipulation" 
is for messages transferred with extensive data conversion. In these tests, an 
array with elements of type integer was convened to an array with elements of 
type real For example, a message size of 1024 bytes required 256 mteger-to-reai 
conversions Under these conditions, transit time was always under 100 millisec- 
onds 

Performance tests for HP Sockets are conducted continually under many environ- 
ments and conditions. The results given here represent a typical environment, 
consisting of a single sending adapter and a single destination adapter, each on 
separate nodes, sending a large batch o* messages If CPU and/or LAN loading is 
normal, these results represent a conservative estimate 
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Startup and Shutdown 

The startup of the HP Sockets run-time programs on the 
various nodes connected by a LAN poses some interesting 
problems. It is necessary to distribute the configuration 
files to all the nodes in the network that need them and 
to coordinate the multistep startup sequence concurrently 
on all the nodes. At the same time, the startup sequence 
must be flexible enough to allow the user to back out of 
the startup sequence at any rime. A further requirement is 
the need to abort the startup automatically if a major 
catastrophe occurs, like the loss of the connection be- 
tween the startup program and the local SMD. Additional- 
ly, the number of nodes that need to be started can far 
exceed the system limits on the number of open connec- 
tions that any process, like the HP Sockets manager, is 
allowed to have. This section outlines how these prob- 
lems were solved and Fig. 10 shows some of the data 
flows between the administration node and a node in- 
volved in the startup process. 

All network connections are established using a connec- 
tion-oriented protocol, such as TCP/IP, 3 Once a connec- 
lion has been established, the HP Sockets manager on the 
administration node, with the help of the local and re- 
mote SMDs, keeps I he connection open until all the steps 
in the startup sequence are completed. The design of the 
SMD allows the HP Sockets manager to request that the 
connection to a particular node be temporarily relin- 
quished, thereby suspending the startup process on that 
node before the sequence is finished. The SMD can also 
automatically undo the startup sequence on a node if the 
network connection between the SMD and the HP Sock- 
ets manager is lost before the entire sequence is done. 

Before beginning a startup sequence, six configuration 
files must be validaled (see "Configuration Files" on page 
13). Configuration file validation converts the files to a 
format that allows them lo be loaded into memory. Once 
the configuration files have been validated, the user in- 
vokes the startup command from the IIP Sockets manag- 
er screen, and specifies (among other things) the directo- 
ry path to the validated configuration files lo be used for 
the startup.* 

The IIP Sockets manager connecls to the SMD on I he 
local node and sets the MajorRequestFlag maintained by the 
SMD lo ensure that the node is not interrupted during the 
startup sequence. This network conned ion lo I he local 
SMD is never relinquished for any reason. If I he connec- 
tion is losl then the startup sequence is aborted on all 
the remaining nodes and an automatic cleanup is per- 
formed by I he SMD on each affected node. 

After setting the MaiorRequestFlag. I he HP Sockets manager 
requests the local SMD to report on I he currem status of 
the local node. The HP Sockets manager then verifies 
thai ihe startup request was issued from the administra- 
tion node, and if not, the startup sequence aborts. 



Fig. 3, HP Sockels message transit time as a function ol message si/e using two HP 3000 
Series 370s 



"there can be more llian one set ol valitfaied configuration files, each in a different direc- 
tory 
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If the user has specified a new configuration file directory 
in the startup call, the IIP Sockets manager copies the 
configuration source files and Ihe validated configuration 
files to its working directory (® Fig. 10). The IIP Sockets 
manager then requests the SMD to load a copy of the 
validated configuration files into local memory, creating 
the run-time configuration table (® in Fig. 10). The start- 
up program extracts configuration information from this 
table to build a singly-linked list (called the domain node 
list) containing all Ihe nodes that are configured in the 
HP Sockets domain (1 in Fig. 10). This list enables the 
startup program to coordinate Ihe network-Wide startup 
of all the nodes by keeping Hack of each node's status. 
While the domain node list is being built, a list of compi- 
lation nodes is also created. 

Compilation nodes are nodes in the IIP Sockets domain 
that deliver and create (via C compiles) data manipulation 
modules for specific machine architecture groups. For 
example, one of the IIP 9000 Series .300 machines in an 
HP Sockets domain would he designated for compiling 
and distributing data manipulation modules to other Se- 
ries 300 machines in the domain. The same would be true 
for each of the other machine architecture groups (IIP 
9000 Series 800. HP 3000 Series 900) hi the domain. See 
"Data Manipulation" on page 20 for more about data ma- 
nipulation modules. 

After the lists are built, the HP Sockets manager connects 
lo the SMI) on each node that has been designated by 
Ihe user for Startup. If il cannot establish a connection to 
a node in three tries, startup on that node is aborted and 
the domain node lisl Ls updated. The connections are all 
established in parallel. When the IIP Sockets manager 



runs out of nodes lo be connected to or cannot make any 
more network connections (because of system or process 
limits) then it waits for responses to come back on the 
connections that have been established. 

To reduce the time required to start up all the nodes in 
the domain, files are copied (pulled) by the SMDs on the 
respective nodes. 

The HP Sockets manager uses a connection management 
table to keep track of all the remote SMDs to which it is 
connected at any lime. The table is an array of pointers 
to the corresponding nodes in Ihe domain node list. The 
status of Ihe network connection from Ihe HP Sockets 
manager lo the SMD on a remote node is kept in the 
appropriate list element. For example, whenever the star- 
tup process is aborted on a node (for whatever reason) 
Ihe domain node list is updated accordingly. 

As a response is received on a connection, the HP Sock- 
ets manager processes thai response and posts the next 
request (in the startup sequence) to lhal SMI). If there 
are nodes that did not get a chance to perform the cur- 
rent step in the startup sequence because there were no 
more network connections available to the IIP Sockets 
manager at lhal time, then the node that just replied is 
temporarily disconnected from the HP Sockets manager. 
The HP Sockets manager then connects to a node that is 
behind in the startup sequence and posts the current re- 
quest. This approach is followed for each step in the 
Startup sequence. Only the connection to the local SMD is 
never relinquished. If there are no nodes lhal are behind 
in the startup sequence then the next request in the se- 
quence is posted to Ihe node lhal just replied. 
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The HP Sockets manager asks the SMD to set the MaiorRe- 
questFlag on that node. (If the flag cannot be set then the 
startup process is aborted on that node. ) After setting the 
Ma/orRequestRag. the HP Sockets manager asks the SMD to 
report on the current status of the node. The startup se- 
quence will be halted on a node if the machine type does 
not match the machine type configured, or the run-time 
programs are running but with a different configuration 
identifier from that used in the startup. 

The IIP Sockets manager checks to see if any data ma- 
nipulation modules need to be built for any of the ma- 
chine architecture groups in the configuration. If a data 
manipulation module needs to be built for a given ma- 
chine architecture group then the IIP Sockets manager 
connects to the SMD on the compilation node for that 
machine architecture group. It requests that the SMD 
schedule the data manipulation module builder. The HP 
Sockets manager then communicates directly with the 
data manipulation module builder and requests it to pull 
the relevant C source file from the administration node 
( 9 in Fig. 11). Then a list of nodes (of that machine ar- 
chitecture group) that require data manipulation modules 
is supplied to the data manipulation module builder ( ? in 
Fig. 11). For each node that needs a manipulation mod- 
ule, the builder 

Compiles the appropriate C source files ( % in Fig. 1 1 ) 
Builds the data manipulation module 



Administration Node 



LAN 



Compilation Node 




Fig. 11. Activities taking place between the administration node and 
a compilation node during starl up and the creation of data manipula- 
tion modules, 



• Distributes the data manipulation module to the node by 
requesting that the SMD on that node pidl it over ( * in 

m id. 

As the data manipulation module builder completes the 
task for a given node on the list it reports the status 
back to the HP Sockets manager. If the data manipulation 
module cannot be built Tor a given node then that node is 
not started. 

After finishing with the compilation nodes, the HP Sock- 
ets manager asks the SMDs on the other nodes W pull 
the validated Configuration files ti III Fig. 10) required to 
build the memory-resident run-lime configuration table on 
that noile. Once this step has been successfully accom- 
plished the SMD is asked to prepare the runtime pro- 
grams on that node for startup. All these steps are per- 
formed on each node in the sequence indicated but are 
done in parallel on all the nodes. 

Once the run-time programs have been prepared for start- 
up on all the nodes designated by the user (and did not 
fail any of the steps outlined above), the user is asked if 
the startup should proceed or be aborted. The user's deci- 
sion is communicated to the SMD daemon on all the 
nodes waiting to start 

When these steps in the startup procedure are completed, 
the SMD on each node is told to transfer (i.e., pull) the 
security file from the administration node ( 4 in Fig. 10) 
SO that all nodes in the domain have the same security 
file. 

The user is allowed to abort the Startup process at any 
lime except when the configuration files are being trans- 
ferred from the user's directory lo the HP Sockets work- 
ing directory and when the data manipulation modules 
are being bum on the various compilation nodes. If the 
HP Sockets manager decides lo abort the startup se- 
quence on any node for whatever reason, then the steps 
thai were accomplished so far on that node are undone 
by the SMD on thai node and the status of the node is 

returned w> iis prestartup state, 

jf the node thai is being started already has the latest 
configuration files available from a previous startup, then 
some of the steps listed above are omitted. This signifi- 
cantly speeds up the startup process. 

The user ran shut down IIP Sockets from the HP Sockets 
manager screen on the administration node. During shut- 
down, the HP Sockets manager uses an approach that is 
very similar to that used during Startup. It goes through 
the same sequence of first setting the MajorRequest Flag 
held by the SMD on the local node. After checking the 
Status of the local node, it connects to the SMDs on all 
the nodes thai need lo be shut down. 

Once the SMDs on all the nodes marked for shutdown 
have been alerted to the impending .shutdown, the user is 
asked if the shutdown should proceed or be aborted. The 
user's decision is rommunicj I lo the SMD OB all the 
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HP Sockets Gateway 



The HP Sockets Gateway product uses a client/server model to extend HP Sockets 
capabilities to machines not using the HP-UX or MPE XL operating systems. The 
client is a user application running on a machine such as an IBM 3090 mainframe 
or a PC The server is an HP Sockets adapter (called a server adapter) running on a 
gateway node, which is an HP-UX node within the HP Sockets domain that has 
been designated to run the gateway server. 

The gateway server maintains a network connection to one or more client applica- 
tions running on the client machine. Even/ gateway node has one server daemon 
for each networking service, it creates server adapters required by the client ap- 
plications. The server adapter provides the functionality of HP Sockets to a client 
application It is also called a virtual adapter since it acts on behalf of a client 
application. 

An application on a client machine is linked with the client HP Sockets access 
routine library. This library lets a client application send or receive message or file 
data to or from any other processes within the HP Sockets domain. The parameter 
list and return values for this library are the same as for the HP Sockets HP-UX 
access routine library. Functional differences between the client access routine 
library and the HP Sockets HP-UX access routine library have been minimized 

The current release of the HP Sockets Gateway uses TCP/IP for interprocess com- 
munication across the network and ftp (file transfer protocol) for file transfers 
Currently software is available for connections to an IBM 3090 mainframe running 
the MVS operating system, or a PC running MS-DOS. 

HP Sockets Gateway Components 

The HP Sockets Gateway components consist of the server daemon, the server 
adapters, the client HP Sockets access routine library, and the client applications. 
Fig. 1 shows the server daemon and three server adapters running on the gateway 
node, MachineA. The dotted lines in the figure indicate that the server adapter 
processes are child processes of the server daemon process Each of the three 
server adapter processes services a client application ThB node labeled MachmeB 
could be a PC running MS-DOS The node labeled MachmeC could be a mainframe 
like the IBM 3090 system 

The purpose of the server daemon process is to accept connection requests and 
create server adapter processes The server daemon is always active, ready to 
create multiple server adapters when connection requests are made It listens at a 
well-known port number associated with the HP Sockets Gateway service. The 
client applications make connection requests to the server daemon through the 
gateway service via access routine library calls. 




Parent/Child Process Connections 

Network Connections 

MRP = Material Resource Planner 

Fig. 1. A server daemon and three server adapters running on the gateway node 
tMachineA). 

Each server adapter is associated with an HP Sockets logical process name. Since 
a server adapter is a virtual adapter, this logical process name is also the effective 
logical process name of its client. The logical process names are entered in the HP 
Sockets process definition file (PROCDEF), described in "Configuration Files" on 
page 13. 

All access routine library calls are serviced by the server adapter on behalf of the 
client application For example, when a client calls the access routine SpReadQ. a 
message is sent over the gateway network connection to the server adapter The 
message contains all the parameters of the SpReadQ access routine call. The 
server adapter then issues an SpReadQ call to HP Sockets using the same parame- 
ters. When the SpReadQ call completes at the server adapter, it returns the output 
parameters and return codes to the client application Except for the Spln'it routine, 
all calls to client library access routines ate handled the same way. 

When a client issues a call to Splmt for the first time, a new server adapter is 
created When the Splnit call completes successfully, the client has a virtual con- 
nection to a dedicated server adapter, and through it to HP Sockets 



nodes wailing to shut down. The user is allowed lo abort 
the shutdown process at any lime. 

Using a single rontrol point for startup and shutdown of 
the entire IIP Sockets domain relieves the user of the 
obligation to start and stop each communicating CPU 
Individually. In addition, IIP Sockets aulomalieally distrib- 
utes all control information lo designated alternate admin- 
istration nodes to prevent the single conlrol point from 
being a single point of failure. This prevents undelivered 
messages from being lost or processes from hanging on 
unfulfillahle reads. 



Data Manipulation 

The dala produced by one program may not be usable by 
a differenl program because the selection of elements in 
that data is not what the receiving program expects. Less 



obvious is the problem of the basic data element types 
not being readable by a receiving program either because 
the sending and receiving programs arc written in differ- 
ent programming languages or because they reside on 
machines lhat have different architectures. 

The same data type passed from one program to another 
can have a different formal in each program if the pro- 
grams were wrillen in different programming languages. 
The same data type sent and received between two pro- 
grams wrillen in the same programming language can 
have different formats if the two programs were compiled 
on differenl machine architectures. Not only can the dala 
type formal) ing be differenl when programs reside on 
different machine types, but the data type sizes and align- 
ments (address locations used in memory) can also be 
different between the two programs. Most of these differ- 
ences are because the language compiler optimizes the 
code by taking advantage of I he data lype efficiencies 
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Fig. 12. A simplified illustration ol 
ihe data manipulation, marshaling, 
and unmarshaling of data in the 
HP Sockets domain. 



and sizing that the underlying machine architecture pro- 
vides. 

A brute-force method of dealing with data type format 
and language-to-machine incompatibilities is to write spe- 
cial conversion routines converting data types from lan- 
guage A on machine type B to language C on machine 
type D. These conversion routines would grow in number 
and complexity with Ihe addition of each new language 
or machine type supported. The amount of conversion 
code would eventually become unwieldy and difficult to 
maintain. Another drawback is that one would have to go 
back and add code to already supported machines to sup- 
port the new language or machine type. 

The IIP Sockets solution to this problem is twofold. First, 
IIP Sockets uses a standard, common way of representing 
values for a particular data type independent of Ihe 
source or target language and machine type. This is 
called common data representation, or CDR. Secondly, the 
application-specific manipulation is done only on the 
sending machines. Fig. 12 provides a simplified illtisl ra- 
tion of what happens when a data structure from applica- 
tion A is manipulated lo be compatible with the data 
structure required by application B, which is on another 
node. Note that CDR conversion is done on both nodes, 
but application-specific manipulation is performed only on 
node A. Ihe sending node. 

Common Data Representation 

Implementation of the common data representation for- 
mal on any system in the IIP Sockets domain requires 
I wo sets of conversion routines for each language sup- 
ported for that machine type: one set to convert from one 
local language into CDR and another to convert from 
CDR back inlo that local language. Going from a local 
language to CDR is called marshaling and going from 
CDR to a local language is called unmarshaling. A big 
advantage of this method is that as new languages and 
machine lypes arc added lo the network, code changes lo 
support Ihe new languages or machine types are isolated. 



The Basic Encoding Rules (BER) of Abstract Syntax No- 
tation One (ASN.l) 4 - * were chosen for the format of the 
CDR data types. ASN.l is an OSI (Open Systems Intercon- 
nection) standard thai specifies the different types of data 
structures that can be transferred between protocol layers 
of an OSI stack. The Basic Encoding Rules define the 
encoding and decoding rules for these data structures. 

As shown in Fig. 12, the target information is marshaled 
and sent with the CDR data so that the receiving side can 
unmarshal and localize the CDR data appropriately. Thus, 
the CDR data is self-describing for eventual unmarshaling. 

ASN.l does not. make the CDR data completely self-de- 
scribing. For example, ASN.l allows marshaling an integer 
into a generic representation. That integer will eventually 
be unmarshaled into a localized integer data type. The 
problem is in determining which local integer data type to 
convert the CDR data into. If the local language is C, Ihe 
CDR integer could be converted into either a short inte- 
ger, integer, or long integer data type. The target data 
type lo use is specified by the user through data defini- 
tion declarations made via Ihe data definition and data 
manipulation languages, or DDL and DMI. respectively. 
These languages make up the application-specific manipu- 
lations shown in Fig. 12. 

This extra, self-descriptive information is called type at- 
tributes. For example, the ASN.l string type encoding 
indicates the currenl size of the siring but not the maxi- 
mum size it should be on the receiving end of the trans- 
fer. This maximum size is included with Ihe CDR data 
and is a type attribute. 

Because of Ihe complexity of the task of data manipula- 
tion and Ihe need for Ihe best performance possible, 
there is tighl coupling between the CDR marshaling and 
unmarshaling routines and Ihe IIP Sockets-generated data 
manipulation code thai calls them. Thus, the CDR rou- 
tines cannot be used apart from the rest of the product. 
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struct! 

char Operalor[2fl): 
ml Month, 
inl Day; 
int Year: 



slruclt 

char Operator|15|; 
char Datelll]. 



DATA DEFINITION 
BEGIN 

P Define structure id as a record named 
input data in DDI'/ 

input data • RECORD OF 
Operator STRING[20| 
Month INTEGER; 
Day INTEGER; 
Year INTEGER; 

' Define structure rt as a record named reponl in 
DDL - / 

report! = RECORO OF[ 
Operator STRINGH5L 
Month ARRAY12I OF CHAR; 

CHAR; 

ARRAY12] OF CHAR; 
CHAR; 
STRINGI5I, 

1 
Id 

/' The format of the Data Manipulation Definition Tile IDMANDEF) is shown below. 

DEFINE MANIPULATION Manipulation-Nairn . 
SOURCE DATA : SourceOalaSfructureName; 
DESTINATION DATA DestinationOataSlruclureName; 

BEGIN MANIPULATION 

<manipulation stalements>; 
END MANIPULATION 

V 

OFFINE MANIPULATION i to reponl; 

SOURCE DATA Input data; 

DESTINATION OATA reportl; 

BEGIN MANIPULATION 

MOVE input_data TO reportl; 

reportl SlashV£' 

reportl. Slash2n*/;' 
END MANIPULATION. 

(d) 

Fig. 13. An example of defining a numeric-to-ASCll conversion in 

Dpi* (a I Original structure in some sending application, (h) Struc- 
ture in which the operator and date information will exist in the 
receiving applkation.(c) DDL definition for the two structures, (d) 
Data manipulation definition for moving the data in a dala struc- 
ture like input.data lo the structure defined in reportl. 



Data Definition Language 

Data definition means defining the format of the dala 
transmitted between processes or applications. Ill' Sock- 
ets uses these data definitions along With the data manip- 
ulations defined via the data manipulation language to 
manipulate the source data so that its format is under- 
standable by I he destination process. 

These data definitions Tor HP Sockets are written in the 
data definition language (DDL), which is a high-level lan- 
guage for specifying the format of the dala exchanged by 
processes. The DDL is used to describe the type and 
structure (logical layout ) of data produced and consumed 
by applications. A data definition is independent of any 
particular computer language's or machine architecture's 
physical representation. 



The DDL serves I he function of a presentation layer simi- 
lar to that of ASN.l in the OSI Reference Model. Howev- 
er, unlike ASN.l, whose primary' putpose is to describe 
how data is represented while in transit across the net- 
work independent of language or machine architecture, 
the DDL is meant to describe how data Should be repre- 
sented at the end points of the communication link — the 
applications. 

This functionality is needed in heterogeneous computing 
environments because different computer architectures 
and languages represent the same information in different 
ways (see Figs. 13a and 13b). Without a description of 
the data, there would be no way to correct the data for 
the representational differences between differing comput- 
er architectures and languages. 

The syntax chosen for the DDL is similar to that or other 
high-level languages, such as C or PASCAL. A lex/yacc- 
based compiler is used to compile the DDL source file 
and lo produce an in-memory symbol table. This symbol 
table is used later to drive the code generator which pro- 
duces the C source files that perform data manipulation 
and conversion to a common data representation. Fig. 13c 
shows the DDL declarations required lo describe the 
structures defined ill Figs. 13a and 13b. 

Data Manipulation Language 

As mentioned earlier, data types and data organization 
may differ between source and destination nodes. There- 
fore, the manipulations that must be performed On source 
data so that it becomes the destination data must be de- 
lined. Manipulations require the definition of the source 
and destination dala contained in the dala definition file. 

Data manipulations are describetl using a high-level lan- 
guage called the data manipulation language (DML). This 
language allows the systems integrator to specify how to 
transform the dala produced by one application so that it 
is more acceptable to another application. Standard trans- 
formations include the ability to reorder the fields in a 
data structure, delete dala fields that are not needed by 
the consuming application, and add and initialize new 
data fields not provided by the source application but 
needed by the destination application. Fig. 13d shows the 
DML statements that define how lo move and manipulate 
data coming from a data structure like that defined in the 
input_data record shown in Fig. 13c lo the reportl record 
shown in Fig. 13c. 

In addition to manipulating the Structure of the dala, ca- 
pabilities have been provided for automatic type conver- 
sion and resizing of data fields. For example, convening 
an integer into an .ASCII string, an integer to real value, 
or a short integer into a long integer. 

As with the DDL, the DML source file is compiled using a 
lex/yacc-based compiler. However, code general ion is post- 
poned until a data manipulation has been completely rec- 
ognized and checked for semantic errors. 
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Data Manipulation Module 

The DDL and DML specifications created by the user 
wind up in the user-defined configuration files.The user 
also indicates the programming language of the sending 
and receiving applications for each manipulation or data 
definition in the link definition file (see Fig. 14) This 
information enables HP Sockets to provide automatic con- 
version between different languages — for example, con- 
verting a FORTRAN t wo-dimensional array (stored in col- 
umn-major order) into a G two-dimensional array (stored 
in row-major order), or a (' string into a Pascal string. 
The languages currently supported in HP Sockets are C. 
FX tRTRAN, Pascal, and COBOL Before HP Sockets is 
stalled up, these files are compiled via DDL and DML 
compilers into C source files and then the C files are 
compiled into execulables called data manipulation mod- 
ules. These data manipulation modules are placed on the 
machines where they will be used. Configuration files and 
the creation of data manipulation modules are described 
on page 13. 

The data manipulation module eliminates the need for a 
sending application to be knowledgeable about the data 
representation required by the destination application. 

Fig. 15a shows the values assigned to a data structure 
like t hat shown in Fig. 13a by a sending application, and 

"The Link Definition file. LINKOEF. contains HP Sockets link definitions. 
* 

This is the lotmat for each entry The numbers in parentheses indicate the maximum 

-length of each field. Optional items are enclosed in square brackets. 

* 

link ■ LinkNamc M ■ MampName 1 0 ■ DalaOelName I NULL 

• (161 (16) (161 
IfSourcelanguagc = SourceLanguage) 

• 

•[SourccFili'Def = SourceFileDelNnme I DEFAULT) 

• (161 
*(DeslLanguage = DestLanguagel 
t 

•DcslFilcDcUDeslFileDclNarnc I DEFAULT! 
« (161 

*SourccNamo~SourceNodeNamc| SaurccNodeName)[SourccNodoNamo] M 

• (16) 116) (16) 
Link = Imkl-M ■ i to reportl 

SourceLanguage = C 
DcslLanguage ■ C 
SouiceName ■ cpul 
I 

This is the end of the link definitions. 

Fig. 14. link definition file for I lie manipulation described in 
Pig 13d 



Application Call 

strcpyf id Operator "Barry Uttl. 
id Month < 1; 
idflay = 36 
itf.Y<M<1990 

la) 

Fig. 15 (;r V.,li„- 
Fig. 2*. (b) After n 
application 



Output 

Operator is Barn imlenam 
Dili is 1/30/1990 



lb) 

<l to the original data st 
Hon and printout from ' 



mm in 

■lion 



Fig. 15b shows the printout from the receiving application 
after data manipulation. 
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Rigorous Software Engineering: A 
Method for Preventing Software 
Defects 



Formal specification languages enable software engineers to apply the 
rigorous concepts of discrete mathematics to the software development 
process. 



by Stephen P. Bear and Tony W. Rush 



Thi> technology base of electronics and computer compa- 
nies like llewlell-I'ackanl is changing — software has be- 
come pervasive. In all market sectors the proportion of 
software in individual products continues to increase. Fig. 
1 shows the dramatic increase of software in products of 
one family developed between 1979 and 1989. 

Product A produced in 1979 was entirely hardware, and 
contained no software at all. Product B contained 38 
KNCSS (thousands of lines of noncomment source state- 
ments) of Pascal. In 198(i. product C contained 200 
KNCSS of structured assembly language, which is equiva- 
lent to about 100 KNCSS of a high-level language like 
Pascal or ( '. The current member of the family, product D 
released in 1989, contains some 350 KNCSS of C. 



Product D 



" 200 




79 80 81 82 83 84 85 88 87 88 89 89 
Year ol Release 

Fig. 1. Software content of a particular medical product family 
fr.in. 1979 to 19K9. 



Growth like this is not accidental because there is a feed- 
back loop that drives the increased functionality provided 
by increased software. Software enables us to design 
products with greater functionality. Initially, this function- 
ality provides a competitive advantage, but it soon be- 
comes essential to success in the market. To make an 
impact, each new product must have more features and 
more software. 

Software Takes Too Long 

This massive change in products, with software providing 
much of the functionality, is happening despite significant 
shortcomings in the current software development pro- 
cesses. The principal problem is that software develop- 
ment takes too long. The development process is difficult 
to control and defect removal can introduce seemingly 
arbitrary delays. 

Delays increase development costs, but more important, 
they also reduce market share and affect overall lifetime 
profit. Studies of high-growth, short-lifecycle markets sug- 
gest that a six-month delay in introducing a product can 
reduce profit by :33%. 1 One IIP Division estimates that for 
each new product, finding and removing bugs can cost 
over 1 million dollars." 

Soliware development takes too long because it is waste- 
ful. Errors and defects are introduced during develop- 
ment, but are not detected quickly. Further work is then 
built upon the erroneous development. When a defect is 
detected, there are many interlocking details, and these 
must be reworked or discarded. During development ibis 
happens repeatedly. Again and again, work carried out at 
one stage is thrown away and must be replaced. 

Defects not detected until late in the software develop- 
ment process can affect large amounts of work. They are 
difficult, time-consuming, and expensive to correct. De- 
fects detected early in the development process require 
less work and typically they are easier and cheaper to 
correct. 

Fig. 2 shows the cost of removing defects detected at 
various points in the software development process, as 
calculated by the software quality engineering group at 
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Many important decisions about overall behavior are 
made by programmers working at the lowest level of de- 
tail. This is not a good way to think about behavior, and 
decisions made in this way are often inconsistent or un- 
desirable. Aspects of behavior emerge from interactions 
that have never been explicitly considered or analyzed. 
Behavioral defects embedded in the code are difficult to 
detect by inspection or review. However, they are the 
defects that begin the costly cycle of rework and waste. 



Specification Design Code System 

Test 

Fig. 2. Calculated cost of defect correction at point of detection in 
the lifecycle. 

one IIP Division. Notice that cosls of removal increase 
exponentially as the development proceeds. 

It is instructive to look at these figures in a slightly dif- 
ferent way. and to consider the cost of introducing an 
error al various points of the development process. Jf an 
error is detected by a code inspection or design review 
soon after it is introduced, it can be fixed quickly and 
cheaply. For example, if a specification error is detected 
al specificalion lime, it will be cheap to repair. However, 
if it is not detected at this stage, then it is likely to lie 
dorniani until the consequences of the error are observed, 
by which time il will be much more expensive (o correci. 

Il tUIIlS out that the introduction and detection of the 
consequences of an error are nested because typically: 
Errors introduced (luring low-level design and coding are 
observed quickly (luring compilaliou and unil lest 
Errors introduced during high-level design are observed 
during Integration and system test 
Errors introduced during specificalion are not observed 
until system lesl and use. 11 

We can use Ibis relationship to estimate the relative cosls 
of introducing a defect al various points in I he develop- 
ment process. II shows that a delect introduced early in 
the development process — and not delected immediate- 
ly — will be much more expensive to fix than an error 
introduced during coding (see Fig. 3). 

Clearly, defect prevention during specification and design 
is extremely important. Getting it tight at this point is 
where il really matters. However, if we look al current 
practice, we see that the analytical and descriptive tools 
used during specification and design are very weak. There 
is little attempt to capture behavior at the specification 
stage. Early narrative documents describe features, but 
these are inevitably ambiguous, incomplete, and often 
contradictory. High-level descriptions of behavior are just 
as vague, and precise descriptions often resort to imple- 
mentation details. 

The result is a rush to code. Developers do not spend 
time understanding and describing behavior because il is 
hard to capture and communicate. Instead they use the 
implementation to document issues and resolve problems. 
Often, the implementation is the first precise description 
of what I lie software will do. 



Rigorous Software Engineering 

Rigorous software engineering is an approach to software 
development that addresses quality and productivity by 
emphasizing the early stages in the development process. 
Rigorous software engineering concentrates on developing 
an early, precise understanding of the required behavior 
Of the system under development. Expensive specification 
and design errors can be avoided, or detected and cor- 
rected before the implementation begins. 

The rigorous software engineering philosophy could be 
summarized as one of defect prevention. Think carefully 
about what you want to do and get it right the first time. 

The approach is to develop an abstract, but precise de- 
scription of the behavior of the software system. This 
description can be reviewed to ensure that the system 
does what is required. If there are problems, they can he 
fixed quickly and cheaply — long before an implementation 
is created. 

Underlying the rigorous approach are formal specification 
languages. These are mathematically based languages Uiat 
provide support for abstract and precise descriptions of 
software systems. 

Rigor in the Software Lifecycle 

Rigor can be used effectively at all stages of the software 
lifecycle. Naturally, if the early stages of the development 
are more error-prone or more costly il" Hawed, then those 
stages are likely to benefit most. 

If we take a simple model of software development — 
specification then design then implementation then test- 
ing — we can show the application and benefits of 




Specification Design Code System Tost 

Development Phase 

Fig. 3. Relative costs of defects introduced in various development 
phases. 
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rigorous software engineering for each stage. In real soli- 
ware development, these phases will appear. Iml they may 
be interleaved, repeated, or omitted. 

Specification. Rigorous techniques are particularly useful 
at the specification stage. A rigorous system of specifica- 
tion is both abstract and precise. Abstraction focuses 
attention on the essential aspecls of behavior. An abstract 
description is not cluttered or confused with irrelevant 
details. It makes the behavior of the system easier to 
understand and to think about. Precision encourages care- 
ful thought because issues must be resolved and cannot 
be hidden in an ambiguous narrative. 

Together, abstraction and precision make it possible to 
communicate the proposed behavior. Reviews and inspec- 
tions can be more effective. Other people can understand 
what is suggested because they can analyze consequences 
and identify problems or omissions. 

The specification of the system will construct a model 
that shows all the required properties of the system. This 
model can be used to resolve difficult issues of behavior. 
If Ihe model cannot resolve these issues, then it is flawed 
and needs improvement. In practice, this makes it diffi- 
cult to ignore tricky areas of the specification. 

A rigorous specification, then, provides benefits to both 
the authors of the specification documents and Ihe re- 
viewers of those documents. Clarity of thought and con- 
cept helps prevent defects from being introduced. Clarity 
of expression empowers reviewers and helps ensure that 
defects are quickly identified and removed. 

Design. A feature of the rigorous software engineering 
approach is Ihe ability to separate concerns. In the Speci- 
fication phase, emphasis is placed on what a system is to 
do. In the design phase emphasis is placed on bow the 
system is to be built because decisions about behavior 
have already been made. It is not necessary to resolve 
requirements issues while doing design. 

Precise spec ifications provide detailed guidance for de- 
signers. Teams of designers know what is to he done. 
This makes it easier for the development to be well-man- 
aged because tasks can be defined precisely (design the 
feature whose specification is as follows) and allocated to 
developers. Misunderstandings causing integration prob- 
lems or system errors can be dramatically reduced. 

It is straightforward to combine the rigorous approach 
with techniques such as structured design. 4, 5 This gives 
many benefits, especially the ability to trace which parts 
of Ihe design implement which parts of the specification. 
This traceability is an important attribute of any develop- 
ment process, allowing subsequent enhancements to code 
to be done in a controlled way and improving the quality 
of the finished software product. The article on page 51 
shows the combination Of Structured design techniques 
and rigorous specifications. 

Good specifications arc especially important when soft- 
ware is developed by subcontractors. Rigorous specifica- 
tions can be made tight enough to allow subcontractors 
to implement precisely Ihe desired functionality, and for 
there to be much less disagreement over the required 
behavior of the system. 



Implementation. As with design, decisions about require- 
ments have already been made. In addition, at this stage, 
design decisions have also been made. Effort is concen- 
trated on producing an efficient implementation of the 
desired behavior. 

The code modules can be traced to the design descrip- 
tions and the design descriptions can be traced to Ihe 
specifications. The vocabulary of the specification is used 
in the commentary for the code — for example, to stale 
properties that particular functions depend on to work 
correctly. 

Testing and Inspections. Throughout the development, the 
deliverables of the various stages can be tested or in- 
spected. Before executable code is available, Ihe specifi- 
cations and design documents can be formally inspected 
using standard Industry practices. 1 ' The descriptions pro- 
vide precise, independent criteria for correctness. In a 
formal inspection the reviewers know what Ihe design or 
code is supposed to do and can check whether it meets 
these requirements. 

The correctness of test cases can also be reviewed 
against Ihe specifications. The behavior of Ihe system 
should be predictable from Ihe specification and tests can 
be chosen to verify this. Industry-standard testing tech- 
niques 7 * can be used to supplement the tests from the 
specifications to catch additional code-orienled errors. 

Formal Specification Languages 

Rigorous software engineering requires precise but ab- 
stract descriptions of behavior. It is possible to write 
these descriptions in a natural language such as English, 
German, or Japanese, but it is very difficult to do so 
without introducing ambiguity and other problems. The 
key to rigorous software engineering is Ihe use of formal 
specification languages to describe behavior. 

Formal specification languages look like programming 
languages in that they both have special syntax and use 
special symbols, but they do very differenl jobs. A formal 
specification language is designed to describe What a 
product is lo do while a programming language is de- 
signed to describe how it is to be done. 

The syntax and symbols of formal specification languages 
are based on discrete mathematics. This can be intimidat- 
ing to begin with, but in fact the math is quite simple — 
far easier than the continuous mathematics routinely used 
by hardware engineers. The math is used to provide an 
abstract mathematical model of the system. This is not a 
new idea since it is the standard approach in engineering 
to use a model to understand the behavior and properties 
of a system. 

One such language is the Hewlett-Packard Specification 
Language, IJP-SL". HP-SI, has been developed at IIP Labo- 
ratories in Bristol. England, and lias already been used on 
real software development projects at several divisions in 
IIP. The language is supported by a toolset (the HP Speci- 
fication Toolset), based on the emacs editor with an op- 
tional interface lo the IIP Soflbeneh 10 product. The tool- 
set allows the production of Specification documents 
containing a mixture of natural language and I1P-SL Us- 
ing the toolset, specifications can be checked for syntac- 
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lie correc tness and for typo correctness. The toolset is 
not a Hewlett-Packard product, but has been made avail- 
able to academic and research institutions. 

HP-SL is a specification language that uses data types, 
functions and logic to describe properties of software 
systems. These properties can lie expressed at both a 
high level of abstraction and a high level of precision. 
This combination of abstraction and precision allows im- 
portant la'havioi tn be captured without becoming lost in 
a mass of detail. 

An Overview of HP-SL 

The HP Specification Language, or HP-SL is a notation 
for describing the beha\ior of software systems and com- 
ponents in an abstract yet precise manner. The language- 
allows attention to Ix- focused on what a system does, 
while deferring dec isions on how a system is imple- 
mented 

The following sections introduce some of the main parts 
of HP-SL. This should provide a useful guide to interpret- 
ing the HP-SL specifications presented in this issue. 

Values 

In HP-SL. values can be given names. These names can 
then be used to represent values. The following declara- 
tion gives the name num to the value 

val num; Int 2 3 

The declaration also says that num is of type Int (integer). 
Int is one of the predefined HP-SL types. A declaration 
need not define exactly which value is chosen for a 
name. For example, 

val numi : Int 

says thai numi is the name for some value of type Int. but 
does not say which particular value is chosen. 1-alc-r sec- 
lions will show thai logic can be used to constrain values 
that an given names. 

Value dec larations can appear al the top level of a speci- 
fication (;is above) in which case their scope is the entire 
specification. They can also be used to define local values 
using a let expression. The let construct is similar CO thai 
found in many functional programming languages. For 
example, the value of the expression: 

let 

val one. Natl ^ t 
val ten: Natl A 10 

in 

one t- ten 
endlet 

is the natural number 11. The name's one and ten are de- 
fined in an inner scope and are nol visible outside the let 

expression. 

Types 

Types in III' SI. are much like types in a programming 
language in llial they are collections of similarly Struc- 
tured values that permit the same set of operations. Thus, 



numbers and Booleans (truth values TRUE and FALSE) are 
distinct types, since arithmetic operators (♦. — . -, etc.) 
work on numbers but not on truth values, and the logical 
oi>erators ( a . v . =>. etc.) work on truth values but not 
on numbers. 

HP-SL provides a number of predefined types and ways 
of constructing brand new types from existing types. HP- 
SL also allows names lo bo given to types. 

Predefined Types. Table I lists the predefined types in HP 
SL These types are available for use in all specifications. 



Table I 
HP-SL Predefined Types 



Name 


Description 


Values 


Bool 


Boolean, truth values 


TRUE, FALSE 


Real 


Real numbers 


0, 3.142. 0.00023 


Int 


Integers 


5, 0, 99 


NatO 


Natural numbers from (1 


9,0 


Natl 


Natural numbers from 1 


9, 1 


Char 


Characters 


'a', '\|newhne|' 


String 


Sequences of characters 


"abc" 



The numerical types (Real. Int. NatO, and Natl) have all the 
expected arithmetical operators defined on t hem (-, — , 
*./.<, >. mod. etc.). The Boolean type has the five stan- 
dard Boolean operators defined on il ( A logical AND, V 
logic-id OR. => logical implication. -> logical negation, and 
logical equivalence). 

Naming Types. In HP-SL, types can be given additional 
names. The following declaration gives the name MyNum 
to the existing type NatO. 

syntype MyNum Q NatO 

This declaration does not introduce a new type, but mere- 
ly gives another name to an existing type. Values of type 
MyNum are indistinguishable from values of type NatO. (The 
keyword syntype derives from synonym typei. 

Constructing Types. HP-SL has some predefined type 
constructors thai provide ways of creating more compli- 
cated types from other types. The most common of these 

are sets, sequences, and maps. 

Sets. These types are used lo model colleclions of data 
for which order and repetition are unimportant. Set types 
in HP-SL are constructed using the iype constructor Set. 
For example, 

syntype Natset ^ Set NatO 

associates the name Natset with sets of natural numbers. 
Values of Ihe set types are Written as follows: 

val empty_set: Natset § { } 
val even_set Natset § ( 2, 4, 6 ) 

where empty_set is a name for Ihe empty set, and eveiuset 
is a name for Ihe sel containing iliree elements -■ 
and 6. 
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For large sets, it is not practical to list all I he values. 
Therefore, HP-SL provides a syntax similar to the conven- 
tional mathematical set comprehension. 

val one_to_a_thousand & { x I x: NatO • x > 1 A x < 1000 I 

The set one_to_a_thousand contains all (he natural numbers 
between 1 and 1000. 

HP-SL provides all the conventional set operators ( U set 
union, n set intersection, £ set membership, \ set differ- 
ence, and C subset). 

3 e {1. 5} = TRUE 
{1.2} U {2,3,4} = {1.2,3.4} 
{1,2} n {2,3,4} = {2} 
{1,2} \ {2.3,4} = {1} 
{1.2} C {1,2,3} = TRUE 

Sequences. These types are used to model collections of 
data for which order and repetition are important. Se- 
quence types in HP-SL are constructed using the type 
constructor Seq. For example, 

syntype Natseq ^ Seq NatO 

associates the name Natseq with sequences of natural 
numbers. Values of this sequence type are written as fol- 
lows: 

val empty_seq. Natseq i <£ » 
val even_seq: Natseq ^ <£ 2, 4 > 

where empty_seq is defined to be the empty sequence, and 
even_seq is defined to be the sequence of two elements, 
the first or which is 2 and the second of which is 4. 

There are a few standard names for sequence operators. 
The names for the HP-SL sequence operators are listed in 
Table n. 



Table II 
Operators for Sequences 

Operator Meaning Example 

hd Head of a se- hd « 2, 99 » = 2 

quence 

tl Tail of a sequence tl < 2, 99 » = < 99 » 

© Sequence con- -C2, 99> © «;2. 99> = 

catenation <2, 99, 2, 99» 

elem Sequence lookup (elem «2, 99» 2) = 99 

len Length of a len <2, 99> = 2 

sequence 

Maps. These types are used to associate values of some 
type with values of another type. In programming lan- 
guages, maps are implemented by structures such as hash 
tables, association lists, and trees. In HP-SL map types 
are constructed directly using the type constructor JV 
For example, the definition: 

syntype Char_to_num ^ Char ^. NatO 

gives the name Char_to_num to the type mapping values of 
type Char to values of type NatO. Values of this map type 
are written as follows: 



val empty: Char_to_num ^ I I 
val amap: Char_io_num ^ I 'a' 



2, 'm' <-> 1, 'p' i-» 1 



where empty is the empty map and amap is the map that 
associates a' with 2, 'm' with 1, and 'p' with 1. 

The function lookup is provided to return the associated 
value in a map. For example, 

lookup amap 'a' = 2. 

Another function, dom, is provided to calculate the ele- 
ments in a map's domain. For example, dom amap = {'a', 'm', 
'Pi 

Introducing New Types. We have already seen ways of giv- 
ing names to types using the syntype keyword. Doing this 
does not introduce a new type, it merely gives a name to 
an existing type. To introduce a new type, HP-SL provides 
the keyword type. This can be used in a variety of ways 
to construct new types, most of which are advanced top- 
ics in HP-SL. The most common use of type is to make 
record and union types. Record types contain values of 
several other types, and union types permit choices be- 
tween alternatives. 

For example, consider a record type used to represent 
boats. To represent a boat in this simple example, we 
only need to know the displacement of the boat and the 
number of engines it has. The type Boat will be adequate 
for this (assume we already have a type Weight to record 
the displacement). 

type Boat t 
| boat l> 

(engines: Natl, 

displacement: Weight) 

1 

This definition states that values of type Boat have two 
fields: engines and displacement. The type of the engines field 
is Natl, while the type of the displacement field is Weight. We 
can construct values of Boat using the name before the 
symbol — boat. 

val single: Boat ^ boatll, 50001 
val double: Boat ^ boat(2, 7000) 

The value single is intended to represent a single-engine 
boat with displacement 5000, and double a twin-engine boat 
with displacement 7000. Just, as in a programming lan- 
guage, the fields of a record value can be accessed. In 
HP-SL, the fields are accessed by functions generated 
from the field names used in the type definition. 

engines(double) = 2 
displacement(single) = 5000 

Consider now a type Ship, values of which are either 
boals (as before) or yachts. Yachts have sails, not en- 
gines, and an important statistic is the sail area We de- 
fine this using the following union type: 

type Ship t 

I boat> 
(engines: Natl, 
displacement: Weight) 

I! 

I 
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I yacht > 
(sail_area Area, 
displacement Weight) 

3 

The symbol "I" Is used to indicate alternatives in union 
types. 

We can irdefine the previous boats as ships: 

val single: Ship A boattl. 50001 
val double Ship ~ boat(2. 70001 
val yacht). Ship ^ yachtl400. 20001 

The field accessing mechanism works as before: 

displacementldouble) = 7000 
displacementlyacht,) = 2000 

Functions 

Functions are used to model computations and calcula- 
tions. Functions in IIP-SL arc "pure" in the sense thai 
they cannot have side effects. 

Functions are defined in one of two ways — explicitly or 
implicitly. An explicit function definition gives a formula 
to calculate a result from the inputs. An implicit function 
definition gives a test or definition of which result is cor- 
rect for the given inputs. To make this clearer, consider a 
function max that returns the maximum of two integers. 

Defined explicitly, a function looks like: 

1: fn max : Int x Int — Int 
2: is max(x, y) 

3: ^ 

4: if x < y 
5: then y 
6: else x 
7: endil 

Line 1 gives the signature* of the function. In this exam- 
ple the signature says that max lakes two values of type 
Int and returns one value of type Int. Line 2 gives names 
for the formal parameters of max, x and y. Line 3 
introduces the body of the function definition, and says 
that what follows will be an algorithm to calculate the 
result given the inputs. Lines 4 to 7 are the explicit algo- 
rithm. 

Defined implicitly, a function looks like: 

1: tn max Int x Int -» Int 
2: is max(x, y) 
3: return larger 
4: post 

5: (larger = x v larger = y) 

6: A 

7: larger >x 

8: A 

9: larger > y 

Lines 1 and 2 of lliis definition are identical to the explic- 
it definition. Line .'I introduces the name larger for the re- 
sult. Line I introduces the body of the implicit definition 
(known as a postcondition, hence the keyword post), 

"A il gr m an dolmes the aigument types and the result lype nl a lunction 



Lines 5 to 9 are a test which Ls true precisely when the 
value larger is the correct result for the function. 

The implicit style can allow quite complicated functions 
to be defined in a simple way, without having to give an 
algorithm. For example, a square root function could be 
specified implicitly as follows: 

tn sqrt: Real — Real 
is sqrtlrl 
return s 
post 

r = s • s 

The square root example as given is, of course, incorrect. 
The square root of a negative real number is not itself a 
real number. A specifier has two choices here — extend 
the definition to complex numbers or restrict the defini- 
tion to nonnegative reals. A particular strength of HP-SL 
is its ability to restrict the scope of function definitions in 
a natural way. This is done by adding a precondition to 
the function definition. This precondition is a Boolean 
test that determines valid inputs to the function. In the 
square root example, the definition given is only valid for 
inputs greater than or equal to zero. Hence the corrected 
definition is: 

fn sqrt: Real — Real 
is sqrt(r) 
pre r > 0 
return s 
post 

r = s • s 

Relations 

For modeling operations on the system state, it is useful 
to identify the particular kinds of functions that return a 
Boolean result, Such functions are called relations and 
have a special syntax in IIP-SL. For example: 

rein vowel : Char 

is vowellcl 

A 

c e fa', 'e', V, 'o', V) 

defines a relation called vowel which is true just for those 
Characters that are vowels. So the expression vowell'a'l is 
TRUE, whereas the expression vowel('k') is FALSE. The mail 
system described in the article on page 32 shows how 
relations are used to model system operations. 

Using Logic 

The use of logic is pervasive iti IIP-SL. Logic can be used 
to constrain values, types, and functions to specify in- 
tended properties precisely without needing to give algo- 
rithms. The implicit form of the function definition is one 
way in which logic can be used. 

Logic can be used to constrain value definitions by using 
the sat keyword. The sat is shorthand for satisfies. 

val x: Int sat x > 10 

val y: Int sat y e (1.9,31) 
This defines x to be some integer greater than II), and y 
to be one of the values 1, 9, or 31. 
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Logic can also be used to constrain types. Consider a set 
Of characters. To model part Of a system, it may be true 
thai these sets can never be empty. HP-SL gives a simple 
way of stating such constraints using the inv keyword (inv 
is short for data type invariant ). 

syntype N_e_char_set 4 Set Char inv s • s { } 

The s between the inv and the ■ is a name thai represents 
a typical member of the type N_e_char_set. This name is 
used in the logical expression alter the - to stale that all 
such members would be nonempty. So the set fa', '6') 
would be of type N_e_char_set but the set { } would not. 
The notion of invariant allows powerful statements about 
expected properties of systems. This aids the production 
and analysis of specifications. 

In addition 10 the simple logic expressions used so far 
(proposilional logic). IIP-SL also provides predicate logic 
Predicate logic extends proposilional logic by introducing 
quantifiers that allow statements about all values of some 
type or about some values. The symbol V, read as "for 
all" or "for any," is used to make Statements about all 
members of some type. The expression 

I V x: NatO • x > 0) 

says that: for all x of type NatO, x > 0. Another quantifier 
is the symbol 3. read as "there exists," which allows 
Statements about some values. For example, the expres- 
sion 

( 3 x: Char • x = 'a') 
says that: there exists an x of type Char such that x = a' : 

Who Has I'sed Rigorous Techniques? 

Rigorous methods are creating increasing interest in the 
software development community. The articles on pages 
4b and &] describe experiences using 1 IP-SI. on real proj- 
ects at two IIP divisions. IIP laboratories Bristol is also 
providing consulting services to IIP divisions in Colorado. 
California, and Scotland. 

Organizations outside of IIP have used formal specifica- 
tions in various ways. For instance, one organization used 
formal specifications to develop a reusable framework for 
a family of software products for instruments. 1 1 They 
concluded thai the application of formally based tech- 
niques in this fashion proved to be cost -effective, and the 
reusability of the specifications has translated into reus- 
able components. Another organization used formal tech- 
niques as part of their reengineering efforts on a major 
software product. 1 - They used the formal notation Z, 
which is very similar to HP-SL, to manage the introduc- 



tion of new features into the product. The specification 
document became a record of the commitment promised 
by the designer to the customer. Many software houses in 
Europe have successfully used formal and rigorous tech- 
niques for a wide range of applications ranging from safe- 
ly-critical applications like air-traffic control to telecom- 
munications controllers. 

Introducing Rigorous Techniques into a Project 

For many people, rigorous techniques represent a radical- 
ly different way of approaching software development. 
Adopting 'bis approach can be far from straightforward. 
In recognition of this problem, the software engineering 
department at IIP Labs in Bristol has a project team 
called the applied methods group, or AMG, whose mis- 
sion is to act in collaboration with other parts of HP to 
introduce formally based methods. 

To date, a phased approach has been taken which starts 
with a small, low-risk project and develops to a more 
substantial collaborative project. It is important that the 
projects have the following features: 

• Enthusiasm from the project engineers to try something 
new 

. Full effective commitment from all tin- managers in- 
volved, from project manager to lab manager 

• Commitment to project-centered training just before the 
collaborative project 

• Realistic expectations of what benefits and costs are in- 
volved. 

In addition, the product being developed needs to have a 
high chance of successful delivery to market. The collabo- 
rations aim to be at the center of the product develop- 
ment, not merely providing an ancillary technology. 

As with introducing any new technology, there are re- 
quirements on the rigorous techniques. These require- 
ments include training, effective technical Support, ade- 
quate documentation, and high-quality supporting tools 
that can be integrated into the normal development envi- 
ronment of the project. A large pan of the team's work 
has been to ensure that this level of support is available. 

Conclusion 

Rigorous software engineering is an approach that is both 
practical and theoretically sound. Its introduction into the 
software engineering community is progressing. It offers 
scope for substantial improvements in software quality 
and productivity. In addition, the approach is likely to be 
developed further to Support a wider range Of applica- 
tions. 
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Specifying an Electronic Mail System 
with HP-SL 



Starting with a list of system features and capabilities, an HP-SL 
specification for a simple mail system is developed and the steps involved 
in this process are analyzed. 

by Patrick C. Goldsack and Tony W. Rush 



Specifications lend lo be used for three main purposes. 
The first is to help analyze the requirements of a system 
by constructing an abstraci model. The process of 
constructing the model, and the subsequent reasoning 
about its behavior, will typically result in extensive dis- 
cussion about the fundamental required behavior of the 
system. The second purpose is to provide concrete, unam- 
biguous descriptions of the system that are open to de- 
tailed review. The third purpose is to act as a guide to 
the developers of the system by describing the necessary 
properties of their programs. 

This paper provides an introduction to using HP-SL nota- 
tion tor the specification of a simple mail system. Al- 
though the mail system and its specification are simpli- 
fied, enough of the system is specified to demonstrate the 
essential aspects of the HP-SL notation and the specifica- 
tion process. Most of the HP-SL notation used in this pa- 
per is described in the article on page 24. 

The System 

The mail system defined in this paper is similar to the 
electronic mail systems in common use such as HP Desk- 
Manager and the various mail systems available on sys- 
tems like the HP-UX operating system. Our example mail 
system has the following features and capabilities. 

The system has a collection of users who are registered 
with the system. 

Each user has diree trays: an injray. an outjray, and a pend- 
ing_tray. 

Users compose messages by entering them into I heir 
pending_tray. 

Users may read and delete messages from their injray. 
Users post messages by moving them from iheirpend- 
ingjray to their out_tray. 

The system transmits messages from a given outjray to 
the recipients* injray. 

A real mail system would provide many more feal tires. 
However, this choice of features is sufficient to illustrate 
the use of HP-SL and demonstrate some of the advan- 
tages of formal specification. 

Building the Specification 

From the natural language description above, wc can 
identify the following entities (data types) that must be 
modeled: 



• Users 

• Messages 

• Trays (injray, outjray, and pending Jray). 

There are also constraints between the entities — for ex- 
ample, each user has three trays. We can also identify 
items of vocabulary that must be defined such as the 
meaning of each of the three tray types and the notion of 
being registered. Finally, several operations are identified: 
. Reading a message 

• Deleting a message 

• Entering a message 

• Posting a message 

• Transniitiing messages. 

Message Data Types 

Entities within a specification are represented as values 
of a type — a concept present in many high-level program- 
ming languages. However, HP-SL has a variety of types 
that are particularly suited to modeling requirements and 
behavior. 

Person. The first type we define is that of person, which 
will be used to represent potential users. 

type Person 

This is an example of an abstract type, hi (his example, 
by making Person an abstract type and providing no func- 
tions that operate on values of the type, we are stating 
that the particular properties and attributes of the type 
are irrelevant to the specification. In fact, the only prop- 
erty we can assert about values of type Person is equality 
(or inequality). 

Contents. The next type is that of the message contents. 
This is also defined as an abstract type. Later, this could 
be refined, for example, into a sequence of bytes. Be- 
cause its structure is unimportant to the specification, the 
type Contents is left abstract. 

type Contents 

Message. To define a message, we note thai there are 
three interesting properties of messages in the system: 

• The idem ily of the sender of the message 

• The identity of the message's intended recipients 

• The contents of the message. 
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In addition, we need to be able lo construct messages. 
We could define Message as an abstract type as before, 
and define functions to construct messages and to extract 
information. 

type Message 

fn message Person ■ Set Person ■ Contents — Message 

fn sender Message — Person 

fn recipients: Message — Set Person 

fn contents: Message — Contents 

The function message will construct messages and the 
other three functions will extract the appropriate informa- 
tion from values of type Message. 

We could also use the following shorthand lo define what 
these functions do. 

type Message ^ 
([ message - 

(sender: Person. 

recipients: Set Person, 

contents: Contents) 

g 

This type is essentially equivalent to a programming lan- 
guage record type. Messages are constructed using the 
function message and the functions sender, recipients, 
and contents are equivalent to field selectors in a pro- 
gramming language. 

Validating the Message Definition 

The definition of the type Message makes certain decisions 
regarding the behavior of the mail system which should 
be validated against the intended properties of the sys- 
tem. In any completed specification document, all formal 
descriptions should be accompanied by a discussion of 
the real-life Interpretation of the mathematical model. If 
one looks at the information captured in each message, 
the following questions and considerations arise. 

Sender. A single person or multiple authors? We decide 
here that the sender field is used lo represent the name 
of the person who actually enters and posts the message. 
This can he compared to the differing approaches of IIP 
Desk and HP-UX mail. 

Recipients. The recipients are expressed as a set of type 
Person. Because a set has no order and no duplicates, the 
consequences of this choice must lie explained. The lack 
of ordering implies I hat no precedence can be given to 
individuals within the set by virtue of their membership 
of the set This seems a reasonable decision for this spec- 
ification. 

The lack of duplicates can be interpreted in one of two 
ways. First, it can mean that a message may not be 
created when a person occurs multiple limes in the recipi- 
ents field of a message. This seems unreasonable if aliases 
for sets of people are introduced and such aliases are 
allowed to overlap. Second, it can mean thai duplication 
of a person in the recipients field has no effecl cm the 
behavior of the mail system. Il is just as though that per- 
son were mentioned jusl once, which in this case is the 
inlended interpretation. If one really wauled the first in- 
lerpivtation there are alternative ways of modeling Hie 
lype that would be more natural. 



Contents. This is a lype for which we have no further de- 
tails about its internal makeup because it has no effect 
on the mail system behavior. This is perhaps one of the 
most significant differences between this example specifi- 
cation and a real mail system. In practice, an arbitrary set 
of conventions is used to give significance to certain 
forms of message contents such as a line starting with 
the character "." or with the siring To:". 

This choice of properties is the minimum necessary for 
this specification example. In a real system, messages 
would have many more properties defined, such as date 
sent and priority. In this specification, these would be 
added as additional fields of the type Message. 

Defining the types used in a system builds up a vocabu- 
lary that can be used to describe the systems properties. 
This vocabulary can be extended to describe all aspects 
of the system in a completely formal and unambiguous 
way. This is done by defining functions that manipulate 
the data at a higher level. Once this extended vocabulary 
is in place, statements of system behavior become 
straightforward. This leads to one of the main benefits of 
formal specification — the right language with the right 
abstractions make discussing design issues much easier. 

For messages, a useful concept is the set of people refer- 
enced within the header of a message — the sender and 
the set of recipients. The function addressed obtains this 
information from a message. 

fn addressed: Message -> Set Person is 
addressed(m) § (sender(m)} U recipients(m| 

The value sender(m) is a set containing only the person 
who sent the message. This is added into the set of recip- 
ients (using set union U) to produce the set of all per- 
sons mentioned in the message. 

Tray Definition 

The initial description of the system mentions three sorts 
of trays that belong to each user. The specification 
groups these three together as a type Trays. 

type Trays ^ 
I trays t> 

(in_tray: Tray, 

outjray Tray, 

pending tray: Trayl 

i 

Each of the three trays is of type Tray, which is defined to 
be a set of messages. 

syntype Tray ^ Set Message 

Note thai this type declaration is slightly different from 
the previous ones. For a start it is introduced by the key- 
word syntype which stands for synonym type. A syntype 
introduces a name for a type, not a new type (unlike a 
lype declaration). Thus the type expression Set Message 
may be used interchangeably with the lype expression 
Tray, 

Validating the Tray Definition 

The decision to model the nay as a set of messages de- 
serves closer Inspection. As previously discussed, using 
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Sets lias tWO COItSequeheeS. Firsl. there is no order in llie 
messages reflected within the tray's Structure, ami second, 
duplicate messages are noi possible within a nay. Hie 

question to be answered is whether either Of these two 

restrictions will cause difficulties in modeling the behav- 
ior, 

Ordering the messages in ;i tray might reflect one of two 
kinds Of attributes: message attributes and dynamic attri- 
butes. 

Message Attributes. These are attributes thai are only de- 
pendent on already existing fields of the mail messages. 
Examples of message attribute orclerings include: 
The alphabetical order ol the senders 
A priority order with the priority of a message being cap- 
tured within the as yet undefined contents field of the 
message. 

This kind of ordering cati be recreated whenever it is 
required, so not capturing this information in the Toy type 
is relatively unimportant, However, in practice it would be 
useful to use an ordered data type if the attribute order- 
ing were centra] to the operation of the system. 

Dynamic Attributes. These arc attributes that are the result 
of some action or ordering of actions. An example Of this 
might lie the order in which messages are placed in a 
tray. It Ls always possible to capture this order by having 
information that represents a message's position in the 
sequence added aS an attribute of the type Message. Ii 
would be heller, however, to take a much more direct 
approach and use. say, a sequence instead of a set. 

Thus a particular choice of modeling is achieved by con- 
sidering both the mathematical properties of the model 
and the directness with which ii captures the intended 
interpretation of the real system. In this instance, mail 
messages in a tray are identified directly rather than by 
position in an ordered sequence, so an unordered Collec- 
tion seems to be a reasonable decision. 

The restriction on duplicate messages is somewhat less 
clear. Consider the injray. The intention is to ensure thai 
recipients only gel a single copy of a message. However, 
this is already indicated for the recipients' being a set of 
people, and therefore, messages are only ever transmitted 
once to an individual The only other way in which a 
message can be sen! iwice is for the sender to do so 
explicitly as Iwo separate send operations. The question 
is whether we wish repeated transmissions to collapse 
identical messages at the receiving end. It is not clear 
that this is an intended aspect of the behavior of the mail 
system. The type used for the injray field could be weak- 
ened to an unordered collection with duplicates (com- 
monly called a multiset or bag). 

Note that there is a temptation at this point to say that 
the undefined contents field might contain a unique refer- 
ence for every message placed in the injray. so that dupli- 
cates caused by repeated transmission in fact result in 
different messages. However, if this were the case, it 
would lie an essential property of the system's behavior 
at the current level of abstraction and so should be mod- 
eled directly. Similar arguments for allowing duplicates 
may be made for the two other trays. For the purposes of 



this example Specification, the type Tray will remain as a 
set to avoid introducing huge amounts of HP-Si, lexl. 

Although this example may be elementary, it is typical 

when using formal specification languages I hat many 
questions arise- both from the process of const meting llie 
specification and from formal reviews of I he specification 
A style is rapidly acquired that questions every modeling 
decision in great detail and considers the consequences. 
This is only possible if the underlying modeling technique 
has a formal basis allowing sound reasoning. 

Willi many data types it is convenient to define additional 
properties that make oilier pails of t lie specification sim- 
pler — in this case, the mail in a tray for a particular user. 
The function maiUor formally defines this property. 

fn mail_for: Person x Tray -* Set Message is 
mailjor (u, trayl 
return msgs 
post 

(V m;Message • 

m £ msgs ** m E tray ah e recipients(m) 

I 

This function returns llie set of messages (msgs) in which 
each message m both is in llie tray (m e trayl and has the 
addressed person u as one of I he recipients (u £ recipi- 
ents(m)). 

System Definition 

The mail system consists of a collection of people, eac h 
with three trays. This associalion is specified by using a 
map from values of type Person lo values of type Trays. 
The following definition stales that each user can only be 
associated with a single collection of Trays. 

syntype Mail_system A Person '., Trays 

Now that the system has been defined, the concept of a 
user being registered on the system can be specified. We 
say that a person is registered if that person is in the 
domain of the system mapping. Hence thai person is 
associated w ith a collection of trays in the system. 

In registered: Person < Mail system -» Bool is 
registered lu, s) 4 u e dom(s) 

The registered function returns a TRUE value if llie person u 
is registered in system s. The type Mail_system will lie re- 
fined later in this specification. 

Operations on the System 

The types of data used in the system have now been de- 
fined along with functions defining additional properties 
of i he data. The operations listed in the informal require- 
ments description can now he defined. 

• I sers compose messages by entering them into their 
pending jray 

• Users may read or delete messages from their injray 

• Users post messages by moving them from their pend- 
ing jray lo their out Jray 

• The system transmits messages from a given out jray to 
the recipients' injray. 
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Entering a Message. The relation input defines the operation 
of entering a message into a user's pendingjray tin prepa- 
ration for sending). This will be defined as a relation be- 
tween the state of the mail system before the message is 
entered, the message to be entered, and the state of the 
mail system after the message has I teen entered. In HP- 
SI., this relation looks like: 

rein input Mail, system • Message • Mail_svstem is 
mput (sys. message, sysi 

g ... 

This relation is true if the parameters are in the relation- 
ship and false otherwise. The input parameters sys and 
sys' are used to indicate the before and after state of the 
mail system (see "Specification of State in HP-SL" on 
page 38). 

When defining operations, il Ls useful to consider what 
constraints can be placed on the operations parameters. 
It might be considered a valid restriction on the use of 
the input operation thai the message placed in the pend- 
ingjray can only be addressed to registered mail-system 
users. If so. this restriction may be Captured using a pre- 
condition, which is a predicaie lhal must be satisfied by 
the input parameters before the operation can be used. 

rein input ; MaiLsystem x Message < MaiLsystem is 
input (sys. message, sys'l 

pre 

(V user G addressed (message) • registeredluser.sysl) 

^ ... 

This restriction imposed by this precondition is artificial 
since it does not prevent a message from being addressed 
to a user who might be dercgislrred from the system 
after the message is placed in the pendingjray but before 

transmission, a less restrictive form of the precondition 

would be to require thai the sender of the message be 

registered with the system. The following definition says 

lhal the sender's pendingjray has the new message added 
to It and lhal this is ihe only change. 

ti rein input MaiLsystem X Message ■ MaiLsystem is 

2: input (sys, message, sys'l 

3: pre registered (sender(message), sysl 

4: A 

5: let 

6. val from g sender (message) 
7: val trays £ lookup sys from 
8 val trays' ^ lookup sys' from 
9: in 

10: dom sys' = dom sys 

11: a 

12: (V p e I dom sys \ (from))- 

(lookup sys' p) = (lookup sys pit 

13: A 

14: injray(trays') = m_tray (trays) 
15: A 

16: out_tray(trays'l = out Iray Itrays) 

17: A 

18: pendingjraylirays'l = pendingjrayltraysl U (message) 
19: endlet 

Lines (i to 8 provide local names for: 

The sender of Ihe message (from) 

The sender's Hays before the operation (trays) 



• The senders trays after Ihe operation (trays'). 

The first two clauses (lines 10 and 12) ensure that the 
system does not cJiange in an unwanted way. The first 
clause ensures that no people are added or removed from 
the system (the domains of the before and after states 
are identical I. and Ihe second clause slates that for all 
but the sender, the system map does not change. 

The final three clauses i lines 14. Hi. and IS) slate how 
the sender's trays change (if at all ). one clause for each 
of the three trays. 

Clauses that state thai the system does not change (lines 
10-12) can be captured in the following relation between 
two states and a person. 

rein change_only: MaiLsystem x Person x MaiLsystem is 
change_only (sys. user, sys'l 

A 

dom sys' = dom sys 

A 

( V p e (dom sys' \ (user)) ■ (lookup sys' p I = (lookup sys pi) 

( liven I his definit ion, input can be rew ritten more succinct- 
ly as: 

rein input MaiLsystem x Message X MaiLsystem is 
input (sys, message, sys'l 

pre 

registered (senderlmessagel. sys) 

A 

let 

val from ^ sender (messagel 
val trays S lookup sys from 
val trays' i lookup sys' from 

in 

change_only (sys, Irom, sys'l 

A 

injrayltrays'l = in trayltrays) 

A 

ouLtrayltrays'l = out_trav(traysl 

A 

pendingjray(trays') = pendingjrayltraysl U (message) 
endlet 

Deleting a Message. The operation delete removes a mes- 
sage from a user's injray. The operation lakes a user (of 
type Person) who is deleling Ihe message and a message 
In be deleted as parameters. The new slate differs firmi 
the old only in lhal Ihe message has been removed from 
the user's injray. The form of Ihe definition is very similar 

to the relation input 

rein delete: MaiLsystem X Person x Message X MaiLsystem 
is 

deletelsys, user, message, sys'l 

pre 

registered (user.sysl 

message 6 injray (lookup sys user) 

A 

changejjnly (sys, user, sys') 

A 

in.tray (lookup sys' user) a m_lray (lookup sys user|\ 
(message) 

A 

outjray (lookup sys' userl = outjray (lookup sys user) 
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A 

pendingjray (lookup sys' user) = pendingjray Hookup sys 
userl 

This relation has a precondition llial states two things: 

• The user is registered (in the domain of the system map) 

• The given message is initially in the user's injray. 

Given thai the precondition is satisfied. Hie remainder of 
(he relation specifies that only Irays associated with the 
user should be changed and that the message should be 
deleted from the user's injray, but the user's outjray and 
pendingjray remain unchanged. 

The second pail of the precondition might be considered 
overly restrictive. The behavior specified in (he precondi- 
tion is actually valid whether the message was there at 
the srail or not (removing a nonexistent element from a 
set leaves the set unchanged). However, this would imply 
that the correct behavior is silently to do nothing when 
the user asks to delete a nonexistent message. In this 
specification we wish to leave open the possibility of 
some other error behavior so we do not fully define the 
operation. 

Posting a Message. When a user wishes to move a mes- 
sage in the pendingjray to the outjray for delivery, the 
postjnessage operation is used. 

rein post_message: Mail.system X Message X Mail_system is 
post„message (sys, message, sys'l 

pre 

registered (sender(messagel.sys) 

A 

message £ pendingjray (lookup sys (sender messaged 

A 

let 

val from ^ sender (message) 

in 

change_only (sys, from, sys') 

A 

injraydookup sys' from) = injraydookup sys from) 

A 

outjraydookup sys' from) = outjraydookup sys from) 
U {message) 

A 

pendingjrayllookup sys' from) = 
pending jrayflookup sys from) \ (message) 
endlet 

The specification states that the message is deleted from 
the user's pendingjray and added to the user's outjray. No 
other parts of the system are changed. 

Transmitting a Message. The next specification defines the 
action of the system in transmitting all messages in a 
particular outjray to their intended recipients' injrays. 

1; rein transmit: Mail_system x Person x Mail_system is 
2: transmit (sys, user, sys'l 
3: pre 

4: registered (user,sys) 

5:^ 

6: dom (sys'l = dom (sys) 

7: a 

8: outjraydookup sys' user) = { ) 

9: A 



10: (V p e domlsysl 

11; pendingjrayllookup sys' p| = pendingjrayllookup sys pi 

12: A 

13: injraydookup sys' p) = 

14: injraydookup sys p) U 

15: mailjorfp, outjraydookup sys user)) 

16: a 

17: p * user => (outjray (lookup sys' p) 
18: = outjray (lookup sys p|) 

19: I 

This specification has a slightly different formal from the 
others. All users are treated identically with respect to 
their injrays (in lines 14 and 15 the messages for the user 
are added to the injray) and their pendmgjrays (in line 11 
the pendingjrays do not change). 

The behavior with respect to the outjrays differs between 
the sender and the other users. The sender's outjray is 
left empty (line 8). The other outjrays are unchanged (line 
17), care being taken to ensure that this clause does not 
apply to the sender by guarding it with the condition p * 
user. 

The clause on line (> ensures that no one is added or re- 
moved from the system by this operation. 

Because every user's trays are potentially altered, the 
change_only relation cannot be used. 

Reading a Message. The final operation is that of reading 
messages. This operation is modeled by the function mes- 
sages_of. which returns the set of messages contained hi a 
user's injray. 

fn messagesjDf: Mail_system x Person — Set_Message is 

messages_of (sys, user) 
pre 

registered(user,sysl 

A 

injraydookup sys user) 
Reasoning About the System 

The primary advantage of formal specifications over infor- 
mal specification techniques is the ability to reason about 
the properties of the specification. This is done for two 
reasons: 

• Since statements about behavior can be written in a for- 
mal language for which there is a sound set of inference 
rules, it can be determined if these statements are consis- 
tent . 

• It can be determined when a specification is complete 
(when the model has been fully defined at the chosen 
level of abstract ion). At this poinl. it should be possible to 
answer all questions regarding pertinent behavior. 

Neither of these properties holds for informal techniques. 
In a normal software iifecycle it is not until the code is 
written (the first complete formal description) that many 
questions regarding behavior can be answered with any 
certainty, either by code reviews or by testing. This is 
typically too late in the project, find contributes to many 
of the problems of software development 

Many questions can be answered purely by inspection of 
the formal specification just as programs can be under- 
stood by examining code. However, formal lechniques 
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also allow properties to be verified formally. This is ac- 
complished by stating a particularly property required of 
the System and then proving I hat the specification satis- 
fies i his property. 

Formal verification in this style is difficult and time-con- 
suming, and current tool support for reasoning is ex- 
tremely inadequate. In practice, it is not expected that 
users of formal teclmiques earn,' out this process in de- 
tail. However, it is always useful to understand how to 
consider properties formally even when carrying out in- 
formal, but rigorously based, arguments. 

As an example, suppose we wish to show that all mes- 
sages in each of the system's mjrays are addressed to the 
owner of that tray. The property can be stated in HP-SL 
with the clause: 

I V sys: MaiLsystem ■ 
I V person t domlsysl- 
( V msg e (in_tray(lookup sys person))- 
person 6 recipientslmsg) 

I)) 

which says that for any mail system sys and for every 
person registered in that mail system, each person is a 
recipient of all the messages (msg ) in that person's m jray. 

This property can be easily disproved by const ruction of 
a counterexample — say a system with one user called A 
wftose injray contains a message addressed to user B. 

What we actually need to show is that this is a property 
that is guaranteed to be maintained by the operations 
provided. In other words, if a mail system is in a state 
where no message has been misassigned to an injray then 
the operations provided will not cause this to happen. In 
addition, since this property is clearly true of an empty 
mail system (one with no messages), and mail systems 
are only created by application of the operations de- 
scribed, then we know that for all achievable slates of 
the mail system this will be true (a proof by induction). 

The proof is trivial because the only operation that adds 
any values to the injray is the transmit operation, which 
clearly maintains the required property The argument for 
the proof runs as follows: 

The initial stale of the system has the property that all 
users have empty trays 

A user's injray is modified by the addition of messages 
generated by mailjor applied to this user 
mailjor returns only mail that has the user in the recipi- 
ents field 

Hence the property is maintained. 

Proofs can be fully elaborated to the required degree of 
formality. However, this kind of scniiformal rigorous argu- 
ment is much more common. 

Adding System Invariants 

If a property such as that jusl examined is true for all 
achievable mail systems, it is useful to highlight it by stal- 
ing that it is a system invariant (a property or relation- 
ship thai must hold for all instances of a particular type). 
In HP-SI., this Van be done by modifying the type defini- 
tion. 



syntype MaiLsystem <i 
(Person Z, Traysl 
inv sys - 
I V user E domlsysl 

( V msg £ injray ( lookup sys used- 
user £ addressed! msgll) 

The definition of MaiLsystem is similar to the earlier defini- 
tion except that a logical constraint has been added This 
constraint is specified by stating that the logical expres- 
sion following the ■ is true for all possible stales of the 
mail system sys. The logical expression states that the 
only messages in users' mjrays are messages that are ad- 
dressed to them. 

The type definition with the added invariant asserts that a 
mail system must never get into a state where the invari- 
ant is false. It is required that every operation on the mail 
system does not break this condition. As we have seen, 
this is true of all the operations so far defined. In addi- 
tion, the definition of each operation can assume that the 
invariant holds when the operation is called. 

In fact, another invariant property exists for the mail sys- 
tem. This is thai the outjray and pending jray of a person 
can only contain messages that have that person as the 
sender. Hence the system type definition with the com- 
plete invariant is: 

syntype MaiLsystem = 
(Person % Trays) 
inv sys • 

( V user e dom(sys)- 
( V msg £ injraydookup sys user) 
user £ recipients(msgl) 

A 

( V msg £ outjrayllookup sys user) U 
pending jraydookup sys user) -user ■ senderlmsgll 

I 

Analysis of the system and its intended behavior may well 
reveal other invariant properties, but for this example 
specification these two will suffice. 

Reasoning is. of course, not limited to invariant proper- 
ties. Other aspects of behavior can be analyzed. For ex- 
ample, the specification has made certain assumptions 
about the behavior of the system when posting a mail 
message that contains an unregistered recipient. The for- 
mal specification gives a way of deciding if assumptions 
such as these are reasonable. 

Limitations of the Specification 

Now that we have a have a specification of a mail sys- 
tem, there are several problems with this model of a mail 
system. 

• The model is lacking many important operations. Ii 
should be clear ihat many more operations on the mail 
system could be added. However, for this paper relatively 
little benefit would be gained so the additional definitions 
have been left Oul for the sake of brevity. 
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Specification of State in HP-SL 

HP-SL is primarily a functional specification language There is no direct concept of 
state variables wilhin the language. Hence there can be no notion of side effect, 
no concept of sequence, and no statements — only expressions This adds to the 
clarity of specifications and facilitates reasoning. 

This does not mean that we cannot describe state dependent systems in HP-SL 
State-related behavior can be modeled in a completely straightforward way If we 
analyze the use of state variables in programming languages, we see that there 
are just two distinct forms. 

• Local variables used in algorithms to evaluate the result efficiently 

• The system state, which is the persistent data that is kept and used by the system 
operations. 

The first of these uses is not relevant when dealing with the style of specification 
used in HP-SL. HP-SL specifications make assertions about behavior with no con- 
cern for run-time efficiency Efficiency is seen as a separate concern which is 
addressed during design, not specification 

However, system state is useful because it gives a very natural style of describing, 
designing, and implementing large numbers of systems To specify system state in 
HP-SL, all that is necessary is a type that can represent all the information neces- 
sary to specify the operations on the system Hence, every possible state of the 
system can be represented as a value of this type. 

Every state-modifying system operation is defined as a relation between the initial 
state Ithe state existing before the operation), any parameters necessary for the 
operation, the result returned by the operation (if any), and the final state (that 
resulting from the call of the operation) 

The typical form of such a relation is. 

rein a_relation System x ... x System 

is a_.relation (sys sys') 

A 

By convention, sys is the name used for state and the initial value of the state is 
distinguished from the final value by the use of an apostrophe f|, Thus, the final 
value is called sys' 



• The model is inadequate because it does not deal with 
issues of concurrency. The specification assumes that 
every operation on the mail system is complete before 
another can start. This is clearly not a reasonable restric- 
tion. Why should users not add messages to their pend- 
ingjrays while others are transmitting the messages in 
their out_trays. 

This concurrency could be modeled at the expense of 
greater complexity in the specification. If the purpose of 
the specification is to reason about Concurrent behavior, 
then this should be done as a separate step. 

• The model is inadequate because it does not deal with an 
unreliable communication medium. 

None of these limitations Invalidates the specification 
when considered as a specification of message address- 
ing, tray manipulation, and so forth. It does describe an 
abstract view of some properties of the mail system but 
it makes no claim about defining all behavior. 

In principle, very detailed models of systems and their 
properties can be defined. However, these are rarely the 
best specifications to write at least as an initial system 
specification. In particular, detailed specifications can 



mask overall abstract behavior and make il harder to 
reason about a system's properties. It is part of the skill 
of using notations such as IIP-SL to decide which aspects 
of the system are important and which may safely be 
deferred. Specification can be used in just those areas 
that are considered likely to be difficult. The specification 
process may be repeated at several levels of detail and al 
different points in the project. 

Refinement 

An important feature of using formal specifications is the 
ability to write specifications of the system in increasing 
levels of detail and to reason about the relationship be- 
tween such specifications. The process of constructing a 
more detailed specification from a more abstract one and 
demonstrating their correspondence is called refinement. 

Refinement is rarely done in practice for whole systems 
(it takes loo much time) but an abstract specification of a 
whole system, followed by detailed specifications of one 
or more key subsystems is practical and useful. As with 
reasoning about system properties, reasoning about the 
correctness of refinement steps can be carried out in an 
informal or semiformal manner as required. 

In refinement, one of the key principles is to show that 
the properties of the abstract specification are maintained 
in the second, more concrete specification. For example, 
in moving to a more concrete representation of messages, 
one might expand the definition of a message to include 
other fields. This moves the abstract specification closer 
to a representation that can be modeled directly in an 
implementation. So. for example, a sequence could be 
used instead of a set since it is typically easier to imple- 
ment a list in a programming language than a set 

type New message ^ 
Unew message ' 

lnew_sender: Person, 
new_recipients: Seq Person, 
creation_date: Date, 
sending_date: Date, 
text: Contents 

I 

1 

The correspondence between this model for a message 
and the one given earlier for type message is demonstrated 
by the use of a function (technically called a retrieve 
function) which shows how the new type represents the 
old type. This is part of a process that shows that the 
more complex type is capable of representing all possible 
values of the more abstract type. 

fn retneve.message: New message — Message is 
retrieve_message|new_msg) 
return msg 
post 

sender(msg) = new sender(new_msgl 

recipients(msg) = elemslnew recipients(newjnsgl) 

A 

contentslmsg! = text(new_msg) 

Given this, the process of demonstrating the correctness 
of this step continues with showing that the new speeifi- 
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cations operatioas behave equivalenUy (0 Ihose of the 
original abstract one. I "nfortunately. this is too complex 
to demonstrate and explain in an introductory paper. 
In principle, refinement could continue all the way to 
code, thus ensuring that the final code implements the 
original specification. I nfortunately the technology need- 
ed to help with the proofs is not yet available and so this 
is not feasible for whole complex systems. What refine- 
ment does give is a definition of what it means to imple- 
ment abstract data types and operations. This definition 
can be informally checked as part of the process of soft- 
ware construction. 



• Creating such specifications forc es the specifier to con- 
front questions regarding the behavior of the system I hat 
might otherwise be overlooked. 

• The ability to reason about the specification is important 
to provide a firm hase for sjM-cification reviews and for 
subsequent coding. 

• Tin- clarification of understanding of a system forced by 
the search for appropriate abstractions is an essential 
part of the system definition. 

• The notation provides a dear and unambiguous state- 
ment of behavior, without the confusion of discussing 
meclianisms and algorithms. 



Conclusion 

This paper has shown how HP-SL formal notations can be 
used in the specification process by discussing a simple 
example. In particular; 
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Specifying Real-Time Behavior in 
HP-SL 



Using the event and history specification features of HP-SL, the software 
for a real-time alarm monitor is specified. 



by Paul I). Harry and Tony W. Rush 



Many of the systems lhal IIP builds must be able to ex- 
hibit real-time properties sueh as concurrency. Therefore, 
it is important to be able to specify not just what hap- 
pens in a system, but also when events happen. This pa- 
per provides an example of using a feature of the IIP 
.Specification Language (HP-SL) called history types to 
specify an alarm monitor for an electrocardiogram (ECG). 

Alarm Monitor 

As pari of the efforts to work with divisions in HP's Med- 
ical Products Group, we in the applied methods group of 
HP's Bristol laboratory were presented with the following 
specification for a raise alarm system monitor ('alarm 
monitor) for ECG measurements. 

• The system monitors incoming ECG measurements and 
compares them with maximum and minimum limits. 

• The alarm is initially c anceled. 

• If the incoming measurement exceeds the alarm limits for 
more than a predefined timeout (delay) period, the alarm 
should be set. 

• When an in-limits value is received the alarm is canceled. 

• The user can enter new alarm limits at any lime. 

• There are initial (default ) limits. 

From this informal specification we can identify three 
states the raise alarm system can be in (normal, delay, 
and alarm), and two values of the alarm (alarm, set and 
alarm_canceled). A constant, t.delay, is the time for which all 
I he measurements have to be out of limits before an 
alarm is raised. Fig. I shows the relationship between 
measurements, alarm limits, states, and the alarm values. 

Alarms, Measurements, and Limits 

From the natural language specification, the following 
HP-SL data type can be denned: 



Alarm Values alarm canceled alarm set alarm canceled 



Measurements 



Normal 


Cdelay 


Alarm 


Normal 


Delay 








Time 


In timits 


Not in Limits 


In Limits 



Fig. l. Measurements, stales. ;m> f alarm values, 



syntype Alarmjimits ^ Real X Real inv (mm, max) ■ min < max 

This type consists of pairs of real numbers, with the add- 
ed constraint that the firsl member of the pair must be 
strictly less than the second. This is a use of the tuple 
data type with an invariant 11 subtype. Therefore, the value 
(9, 100.5) is of type Alarmjimits but the value (9. 2.5) is 
not. 

There is some default value for the alarm limits. We shall 
merely state that this constant is of type Alarmjimits. bill 
not give ;in actual value. This is an example of under- 
specificalion. 

val default, limits: Alarmjimits 

The alarm itself can be either set or canceled. 

type Alarm ^ J alarm_set J I [ alarm_canceled 11 

The type Alarm is modeled as an enumerated type with 
the two (distinct) values alarm_set and alarm_canceled. 

The incoming measurements, which are constructed from 
the Et'G wave, are simply real numbers. 

syntype Measurement ^ Real 

A given measurement is either within the alarm limits or 
not. This can be observed by the function injimits. 

fn injimits Measurement X Alarmjimits -» Bool 

is 

injimits(value, (min, max)l 
A 

min < value a max > value 

So. for example, the expression: injimits(5, (2. 9.51) is true, 
whereas the expression: injimitsd, (2, 9.511 is false. 

The raise alarm Process 

We can specify this system by the raise_alarm process. Fig. 
2 is a first attempt at drawing a data flow diagram for 
this process. The process lakes two inputs (the alarm 
limits and the measurement) and produces one output 
(the alarm state). In the data How diagrams of structured 
analysis, the flows consist of individual values. For exam- 
ple, the meas flow consists of individual values of type 
Measurement. 

The behavior of I he raise.alarm process depends not .just 
on one measureineni. but rather on many previous mea- 

■ An invariant is a property ,na! musl dl ' ,va vs ne maintained for a particular type 
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Fig. 2. Initial ilala flow diagram <if tin iaise_alann process. 

surements. In other words, the behavior depends on the 
entire history of measurement values. In structured analy- 
sis the necessary historical information would have to be 
saved within process raise_alarm, which would be done by 
decomposing the process into subprocesses and a data 
store. Fortunately, there is a more direct way of specify- 
ing the behavior using a style of specification known as 
history specification. Instead of defining a process in 
terms of the current values on its data flows, history 
specifications define the process in terms of all the pas! 
values on the flows, that is. in terms of histories of val- 
ues. 

History "types 

There are two forms of histories, event histories and state 
histories, each reflecting different time properties. 

Event Histories. Event histories model flows that have 
events occurring at discrete limes. Examples of event 
histories include: 

Pulses from a revolution counter on a car drive shall 
Debits and credits on a bank account 
Button presses 

The incoming measurements in the ECG alarm system. 

Event histories are characterized by the significance of 
duplication. For example, two debits to a bank account 
(even if they have the same value) are different from one 
debit. Event histories can be illustrated by a timeline as 
shown in Fig. 3. 

The timeline diagram shows: 

The stall lime and end time of the history. In Fig. 3 the 
stall time is to, and the end time is 15. This gives the time 
interval over which this history models the events. 
The events, shown as X symbols. Each ev enl has a value 
(shown above the line) and a time (shown below ihe 
line). For example, in Fig. 3 there is an event with value b 
at lime t3. 

Event histories are modeled by the HP-SL lype conslrue- 
lor Hist e . For example, a hislory of measurement events 
would have lype HisMMeasurement). 



The expression umes(h) is the set consisting of all the 
times of events in history h. Using the history h„ defined 
in Fig. 3: 

timeslhJ = { t2, t3, t4 | 



Time 



10 



11 12 13 17 rt 18 15 

Fig. 4. A state history, 

The operators starts and end e return the start and end 
times of an event history. From Ihe example history in 
Fig. 3. 

start e |h e | = tO 
end„(h e ) » t5 

Given an event history h. we can find the value of the 
most recent event relative to some time t using the ex- 
pression previous_evem(h, t). The result is undefined if there 
is no event at or before time t. Returning to the example 
history: 

previous_event(h e , t3l = b 
previous_event(h e . t7l = b 
previous_event(h 8 , til /* not defined 7 

Finally, a time range can be checked using the operator 
m_interval e . For example, the expression 

t 'in_interval B h 

tests whether a lime t is within the range of limes cov- 
ered by Ihe history h. From Fig. 3. 

t7 'mjnterval h c = TRUE 
t6 'injnterval h„ = FALSE. 

State Histories. Slate histories model flows I hat always 
have a current value. Examples of state histories include: 

• Distance t raveled by a car 

• The balance in a bank account 

• The current condition of a switch (e.g., on or off) 

• The alarm limits in Ihe ECG alarm system 

• The slate of the alarm in the ECU alarm system, 

State histories are characterized by Ihe insignificance of 
duplication. For example, if the bank balance is overwrit- 
ten twice iii succession with the same value, this is indis- 
tinguishable from overwriting once. Further, state histo- 
ries always have a possibly tindcrspecified initial value. 
Stale hislories can be illustrated by the graph shown in 
Fig. 4. 

Slate histories are modeled by the lll'-SI, type constructor 
Hist 5 and just like event hislories. stale hislories have end- 
point operators written as: start s and end s . The current 
value of a slate hislory is found by Ihe expression h@t. 
Since state hislories always have a current value, this 
operator can be applied at any lime within Ihe endpoints 
rime of ii„. history. The following formulas hold for Ihe hislory 
' illustrated in Fi«. I. 



Fig. 3. An event history, h,. 
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in h . Hist, (Event) 




A 

oul h . Output,, 

Fig. 5. A count process. 

start s |h s l = tl 
end s (h s ) = t5 

h s @ t7 a b /' at time t7, h s has value b 7 
h 5 @ t4 = b 
h s @ t8 = c 

I V t: Time sat t3 s t A t < t4 • h 5 @ t = bl 

Note that the use of sat on the last line constrains I to lie 
between (3 and t<l. 

Specifying Processes 

In history specifications processes are specified by relat- 
ing entire histories of inputs to histories of outputs. In 
Fig. 5 the process count has input of type Hist e IEvem|. and 
an output of type Output,,. The input models a stream of 
events. The count process outputs a continuously updated 
count of the number of input events received. Since the 
output is continuously updated, it is modeled by a stale 
history. The following invariant ensures that the initial 
value of this history is zero. 

syntype Output,, = Hist 5 i NatO ) inv h • h @ start s |h| = 0 

Using an III'-SL relation the count process is specified as 
follows: 

rein count : Hist,, (Event) x Output,, 

Is countlin,,, out n ) 

a. 

let 

val now ^ end e (in h | 

in 

out,, @ now = number_of_events(in h | 
endlet 

The local value now is set to I he end time of Ihe history 
of input events. The left-hand part of Ihe main expres- 
sion, out h @ now. is the current value of the output state 
history. The right-hand pail, number of events(in h ), is the 
number of events in the input history. 

This is Ihe usual form in which we present history speci- 
fications. However, the history specification alone does 
not say enough. The output history is only parti) defined 
because we have defined its value at the end time, bill 



have said nothing about its values at earlier times. We 
really wan I the relation between the current output value 
and ihe number of events applied throughout Ihe output 
history. To do this we should surround the above relation 
with a universal quantification (V, read as "for all") over 
all times along ihe histories. Fortunately, the notation 
used in history specifications does this Tor free, so there 
is no need to write it ourselves. 

The overall meaning of the count process specification is 
therefore: 

At. any time, the output hisiory of the system (outh) is 
correct with respect to the given input history (inh) if 
the current value of the output history equals the num- 
ber of events in the input history. 

Using the Histories 

Fig. 6 shows the data flow diagram for the raise_alarm pro- 
cess with Ihe correct types on the data flows. Dolled 
lines are used for event histories and solid lines for state 
histories. 

The type definitions for the input and output histories 
shown In Fig. 6 are defined as: 

syntype Measurement,, s Hist,,(Measurement| 
syntype Limits,, § Hist s IAIarm_limitsl inv h • 

h @ start s (h| = default limns 
syntype Alarm h g Hists(Alarm) 

Note that Ihe types Limits,, and Alarm h are declared to be 
state histories, whereas the type Measurement,, is declared 
to be an event history. This is a suitable modeling choice 
because there are initial values for the alarm and both 
alarm limits, whereas there is no initial value for mea- 
surements. Indeed we shall see that one of Ihe functions, 
injimits,,, needs to test whether there have been any mea- 
surements before a given time. Such a test is not mean- 
ingful for a slate hisiory. 

We can now start to define ihe process by the relation: 

rein raise_alarm (Measurement x Limits,,) X Alarm,, 
is raise_alarm((meas. limits), alarm) 

A... 

limith' limits,, 




meas,,. Measurement alarm,,: Alarm h 

Fig. 6. Data flow iliagraiii of the raise_alarm process with the correct 
data flows. 
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History Specifications 



The ECG alarm example shows only a small pan of the power of history specifica- 
tions Other features include 

Unified Graphical Notation, r&tory specifications combine the accessibility of 
a graphical notation with the power of a textual one Special graphical notations 
are provided for the most commonly used process specification idioms 

Composition. Processes can be composed together to specify larger systems For 
example, we could ado processes lo the alarm system to change the alarm limits, 
and to veto the alarm This feature >s illustrated by the composition diagram 
shown in Fig 1 

Specification Styles. The state and operations style of specification used for the 
mail system (see page 321 can be incorporated into history specifications For 
example, ihe composition diagram for the mail system is shown in Fig 2 

The following guidelines could be used to determine which specification style to 
use 

• Use state-based specifications when 

The sysiem is similar to a database It is surprising how many systems 
can be partitioned into a central data siore accessed by read and 
update operations. 

The system has few properties dependent an time 

The structure of the sysiem is sufficiently simple not to need a graphical 

index to the system 



max limit, slep mi" limn slep 



measurement 



vetoed alaim 



. eMUMNnaHl i 



• • © 



new message 



usei message 



user message 



fig. 2. Composition diagram for ihe mail system 



Fig. |i Composition diagram for Ihe alarm system 



• Use history specifications when 

The system has many properties dependent on toe 

The hierarchical structuring oi data flow diagrams is adequate, but their 

ambiguity and limitations are not 

The system is structured into a core and concentric outer fringes 

Implementation route. There is a systematic implementation route from specifi- 
cation to code via structured design This route consists of five steps. 

• The starting point is the history specification in which processes relate whole 
histories o> values 

• The history specification is treated as a classical data flow diagram and trans- 
formed into a structure chart This structure chart will also be in lerms of whole 
histories. 

. No implementation can handle histories, so each history must be replaced bv the 
data thai needs to be stored For example, in ihe count process the history of 
incoming events is replaced by a count so far The result is known as the reduced 
design 

• The reduced design is upnmized. 

• Module specifications are written This is usually only necessary when optimi/a- 
lion has made it hard to understand ihe modules from the original process specifi- 
cations 



Detecting Out of Limits Values 

In an earlier section that described alarms, measurements, 
and liinils. a Boolean function, injimits. was defined Which 
is irue when a given value of the EC'(i measurement is 
between given alarm limits. The alarm monitor's behavior 
depends nut jusl on whether the current measurements 
are in liinils. hut also on whether older measurements arc 
in limits. To do this we define a function injimits,, over the 
histories Measurement^ and Limits,,. This function returns 
true if. at a given time t. the measurement is in limils, or 
if there have been no measurements. 

fn injimitsi, : Measurement x LimitSh * Time — Bool 

is in limitShlmeas, limits, t) 

pre 

II 'in interval c measl a |t 'in_interval s limits) 

A 

I 3 tl c times(meas) • tl s t| 
in_limitslprevious_event|meas. I), limits @ t ) 



The precondition uses the (Mictions 'in.. interval and 
in_interval s to ensure that the histories are defined al the 
given time. t. 

Deciding if there have been any measurements yet is 
done by Ihe expression: 

( 3 tl 6 times(meas) t! £ tl 

which is true just when (here is at leasl one event al 
some lime tl in the history mens earlier than time t. (The 
existential operator 3 is read as "there exists" or "there 
exisls one or more.") 

The (Unction returns a defaull value of TRUE if there are 
no measurements before the given Ume t. If there are 
earlier measurements, then the value of the current hum 
suremenl is found by using Ihe previous_event operator. The 

current limits are found by using the current value opera 
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lor (@) at the given lime i. These measurement and limit 
values are then compared using I he mjimits function. 

Alarm Detection 

From the natural language specification lor the alarm 
monitor it is clear that: 

• The alarm is only set after all measurements have heen 
outside the alarm limits for a given lime 

• Any occurrence of an in-liniits value cancels the alarm. 

The value of the time delay before out-of-limils values 
cause an alarm is not important to this specification. 
Instead, a constant is defined without specifying an 
associated value. 

val t_delay: Time 

hi practice, the value of this constant would he con- 
strained to he within clinically acceptable limits. 

For an alarm to be raised at a particular time, called now. 
the value of the measurement history must have been 
consistently out of limits for a lime t_delay. Hence at any 
particular lime, a key value is the portion of Ihe measure- 
ment history Occurring between now and now - t_delay. In 
fact, of most Importance is (he value of ihe [unction 
inJimitSh al <>" linies between the interval now and now - 
t delay. Informally, an alarm will be raised only if in_limits h 
is FALSE al all linies in this time interval; So. for an alarm 
lo be raised al time now. Hie following condition should 
be TRUE. 

IV t: Time sat (now - t_delay) < t a t < now • 

-• inJimitSh! meas, limits, t I ) /" - = unary operator not"/ 

This is BOl quite enough since il fails to take into account 
the behav ior of ihe system w hen il starts, that is. when 
now - t_delay < starLtime. The normal way to specify such 
a condition in HP-SI. is to use Ihe existential quantifier 3. 
Informally we can say that an alarm condition exists if 
(and only if) the syslem has been operating for al least 
lime t_delay, and for all linies between now and now - t_delay 
the measurement was not in limits. This can be expressed 
formally as follows: 

( 3 t 5 = (now - t. delayl sat t 5 > start_time - 
I V t: Time sat l s < t a t < now ■ 
=1 in_limitS|,l meas, limits, t III 

This expression is true only when we call construct a 
lime (t s ) that is t_delay before now and after the stall lime, 
such I hat the value of the measurement history is out of 
limits at all linies between t 5 and now. In particular, the 
expression cannot be true until now is greater than t_delay 
( because no valid t s can be constructed). 

Final Specification 

The following is the final specification for the raise_alarm 
process. 

• Alarms, limits, and measurements: 

syntype Alarmjimits ^ Real x Real inv (mm, maxl - min < max 
val defaultjimits: Alarmjimits 

type Alarm ^ J alarm_set H I J alarm_canceled J 
syntype Measurement ^ Real /'ECG measurements from 
patient*/ 

fn in_ limits Measurement x Alarmjimits — Bool 



is injimitslvalue. (mm. max)) 
A 

min < value a max > value 

• History definitions: 

syntype Measurement ^ Hist e (Measurementl 
syntype LimitSh = Hist s (Alarm Jimitsl inv h - 

h @ stanch) = defaultjimits 
syntype Alarm h £ HistslAlarml 

• Detecting out-of-limil values: 

fn inJimitSh : Measurement x LimitSh x Time — Bool 

is in hmitShlmeas, limits, t) 

pre 

It 'injnterval 0 meas) a (t 'm_interval s limits! 

A 

( 3 tl e times(meas) - tl s t) 

inJimits(previous_eventlmeas, tl, limits @ 1 1 

• Alarm deleclion: 

val t_delay: Time /* duration of out-of-limrt values needed 
to raise the alarm'/ 

rein raise_alarm (Measurement!, X Limits h l X Alarm,, 

is raise_alarml(meas. limits), alarm) 

A 

let 

val now = end e (measl 

val startjime = start B (meas) 

in 

if 

( 3 t s = (now - t_delay) sat t s > start jime • 
I V t . Time sat t s < t a t < now • 
-> in limrtShlmeas, limits, till 

then 

alarm @ now = alarm_set 
else 

alarm @ now = alarm_canceled 
endil 
endlet 

Exploring the Specification 

One of the advantages of specifying a syslem formally is 
thai the specification provides an opportunity to reason 
about the syslem and the consequences of the choices 
made. For instance, some of the questions that can be 
raised about this example include: 

• Is ihe system's behavior at startup correct? 

• What exactly happens when •><> ECG signal is received? 

• What happens w hen alarm limits are changed? 

On startup, no alann can be raised. This is ensured by 
the test in the if expression of raise_aiarm being false. 
Hence the output value is alarm_canceled. This would seem 
to be correct when evaluated againsi the informal require- 
ments. 

When no ECU signal is received, the value of injimitsi, is 
found by looking backwards in the measurement history 
for the List received measurement. Hence, if the lasl mea- 
surement value w as out of range, an alarm will be raised 
after t_delay. If the last value was in range, no alann will 
he raised. If there have never been any values, the default 
behavior of injimitsi, ensures that no alarni is raised. 
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When limits are changed, the function m_limits ft automati- 
cally uses the new value of the limits to test incoming 
values. An interesting case is when the limits are changed 
and no ECG measurements are received. In this case, the 
most recent value on the ECG input is compared with the 
new limits. This has the consequence that an alarm might 
be raised even though no new ECG data is received be- 
cause the limits have been changed. Is this the correct 
behavior? 

The answer is that this is a feature of the product that 
needs to be decided. This question can lie fed into the 
normal product requirements definition activity-. The use 
of a more formal specification highlights these boundary 
cases at an early stage in the software development pro- 
cess. 

Conclusion 

This article has introduc ed I he history data types of 1IP- 
SL. and has shown how they are used in history specifi- 



cations to specify processes. We have found that in prac- 
tice this style of specification works extremely well in 
describing embedded systems. For example, see the ar- 
ticle "Formal Specification and Structured Design in Soft- 
ware Development" on page 51. 

History specifications are an attempt to combine the best 
features of formal specifications and structured analysis. 
Like structured analysis, they have an accessible graphical 
notation that allows a large system to be decomposed 
into a hierarchy, Like formal spec ifications, they have a 
rich data language and a fully defined meaning, and sup- 
port abstraction or underspecification. In addition, history 
specifications allow properties involving time to be stated 
very directly. A problem that might require a control 
specification, a data store, and several subprocesses in 
structured analysis may only require a couple of functions 
when using histories. 
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Using Formal Specification for 
Product Development 



In one product development project, the use of precise software 
specifications helped to uncover potential problems that might ordinarily 
be overlooked, and raised some interesting issues about using formal 
techniques. 

by B. Robert Ladeau and Curtis W. Freeman 



Early in I98S* a collaboration was sel up between a proj- 
ect team at the cardiac eare Systems tecs) business unii 

ai Ill's Wallham Division and Ihe applied methods group 
(AM(I) al HI' Laboratories in Brislol. England. The collab- 
oration involved project engineers From both groups, with 
communication taking place through a few cm-site visits 

and a lot of' -electronic-mail correspondence. 

At a very high level, the goal for both groups was to im- 
prove the quality of the software that was lo be devel- 
oped. There were additional goals specific to each group. 
We at Walt ham were interested in adding more discipline 
to our software development process and learning more 
abOUl formal methods, Goals specific to Ihe AMG were to 
transfer Ihe lalesl software development technologies to 
other IIP divisions. I" our case this meant enough train- 
ing and support in Ihe III' Specification Language (lll'-SL) 
to enable us to write our own formal specifications. In 
return, Ihe AMG engineers would gel feedback from proj- 
ects within III' product divisions specific to their research 
interests al III' Laboratories. 

This paper reviews (he results of our collaboration involv- 
ing the introduction and use of formal Specification dur- 
ing Ihe development of a medical product software en- 
hancement. We discuss tin- lessons learned during this 
process of introducing an advanced software engineering 
methodology into an R&D environment We also describe 
Ihe specific achievements and problems that were experi- 
enced in using formal methods to specify parts pf the 
software functionality' 

The Project 

The project al Walt ham was created lo add a new feature 
(ST segment measurement ) to an existing medical prod- 
uct. The product is a bedside monitor thai is used lo 
monitor vital signs of patients in intensive care units and 
operating rooms. ST segment measurement is a measure- 
ment of the change in a portion of a patient's electrocar- 
diogram (EGG) called the ST segment (see Fig. 1). 
Changes in (he ST segment of a persons ECG can indi- 
cate reduced blood How (ischemia) to an area of the 
heart. These changes ma} be clinically significant in cer- 
tain patient populations, specifically patients who have 
had heart attacks. Changes in this portion of an ECG 
waveform occur slowly, can be asymptomatic (produce no 
pain or discomfort ). and are often hard lo detect by (he 
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Fig. l. EGG for One cantia cycle (one heart best). 

user (physician or nurse). By providing this functionality 
in a patient monitor, we aim lo supply Ihe user with an 
early warning thai one of these episodes of silent isch- 
emia is occurring. 

Using HP-SL 

As described in the article Otl page 21, lll'-SL is a nota- 
tion for describing systems and components in an ab- 
stract yet precise manner, allowing a user to focus atten- 
tion on what a system should do and defer details 
relating to how to build the system until later stages of 
development. During this collaboration, we used lll'-SL to 
create abstract yet precise descriptions (models) of vari- 
ous bits and pieces of Ihe software lo better understand 
Ihe desired behavior early in Ihe development process. 

The software developed on this project continuously mea- 
sures a portion of an ECG complex called tin- ST seg- 
ment Modeling Ihe ECG wave at an abstract level makes 
il easy to understand and capture (document) essential 
properties of an ECG wave, properties thai must exist for 
valid ST measurements to be made: 

Modeling the ECG Wave 

Tin' ECG data lhat is input to Ihe ST segment measure- 
ment algorithm is basically a stream of voltages (see Fig. 
2), along with some configuration information such as: 

• Thi' voltage source (the lead) 

• How much filtering has been done on Ihe signal (Ihe 
bandwidth) 
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EGG leads 



Wave oonlont information such as which voltages repre- 
sent usable patient information and which are invalid (the 
validity ) 
Time. 

The ST algorithm uses this incoming EGG data and other 
information to find and measure the ST segment of an 
ECG wave. If an ECG wave is measurable, an ST mea- 
surement will be produced. To capture the notion of mea- 
surability it is helpful to be able to look at the problem 
at an abstract level without concerns about resource lim- 
itations. ECG data is received as a sequence of wave 
samples that includes all the information mentioned 
above. Therefore, an ECG wave sample can be viewed as 
the cross product of these elements, and can be modeled 
using an HP-SL record as: 

type Wave_sample 4 

Jwave_sample C 

(voltage : Ecg_voltage. 
validity Validity, 
lead Lead, 
bandwidth: Bandwidth, 
time : Time) 

i 

An ECG wave can then be modeled simply as a sequence 
of wave samples: 

syntype Ecg wave ^ Seq Wave_sample 

Now the notion of measurabilily Ctti be specified. An 
ECG wave is measurable if all of Ihe wave samples are 
valid, have a specific bandwidth (0.05 Hz high-pass), are 
derived from the same lead, anil are continuous in lime. 
I 'sing HP-SI. this property can be expressed as a relation- 
ship involving the elements of a wave sample. 

teln measurable : Ecg_wave 
is measurable |ecg_wave) ^ 

( V (wv_sample1 e elems (ecg_wave|). 
validity(wv_sample1) = valid 

A 

bandwidth(wv_samplel) = hz_.point05 

A 

( V Iwv_sample2 E elems (ecg wave)). 
lead(wv^samplel) ■ leadlwv sample2)| 

A 

continuous (ecg^wavel) 

The final relalion, called continuous, specifics Ihe require- 
ment thai the wave segment must be a continuous stream 
of wave samples (no gaps). This relalion simply States 



that if two wave samples occur one after the other in 
sequence, the time associated with the second wave sam- 
ple is one time unit after the time associated with the 
first sample. With HI'-SL this notion is expressed as: 

rein continuous : Ecg_wave 
is continuous (ecg_wave) ^ 

( V (i e inds (ecg_wavel, j e inds (ecg_wavell- 
j = i + 1 => 

lime(ecg_wave(j)) ^> successor(time(ecg_wave(i|)ll 

The HP-SL operator inds returns the indexes of a se- 
quence. 

In our produc ts an ECG wave is typically implemented as 
a stream of data that consists only of voltages. Because 
of resource limitations (CPl" lime, RAM), the other in- 
foniialion (validity, lead, etc.) is input via separate data 
si reams where the data is updated less frequently This 
works line in an implementation if Ihe developer knows 
what the relationship is between the streams of voltages 
and other data, so that changes in validity, for example, 
can be associated with the correct voltages. Problems 
arise if Ihe developer hasn't learned, or forgets, these 
implicit relationships. 

The model shown above makes these relationships explic- 
it. For example, the requirement that all wave samples be 
derived from the same lead has been made explicit and 
available for review. By modeling Ihe problem at an ab- 
stract level, implicit relationships can be made explicit. 
I IP-SI. provides a framework for making important prop- 
erties explicit and increases the chance that an important 
property will be maintained across different implementa- 
tions. 

A Problem Uncovered 

The process of understanding and specifying the notion of 
measurabilily uncovered a problem in an existing product. 
An ST measurement is actually made on a beat (see Fig. 
1). A beat is a portion or an ECG wave that represents 
the electrical activity present during one cardiac- cycle 
(one heartbeat). When a measurement is made. Ihe corre- 
sponding beat is displayed to ihe user for review. 

In one case the requirement that all of Ihe wave samples 
thai make up a beat be valid was not met. If a certain 
mixture of valid and invalid samples was present, the 

iieai would mistakenly be considered measurable. The 

result was benign (the ST measurement was labeled inval- 
id), bill il was possible to display a strange looking beat 
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for a short amount of time. Our effort lo capture a pre- 
cise, abstrael notion of measurability marie this hidden 
problem visible for the first time. 

Focus on Precision 

One benefit lhal we noticed from our introduction to for- 
mal specification was that an emphasis on precision 
started to pervade our development process. We found 
lhal uncovering potential problems was pushed lo aji ear- 
lier stage of the development process than would have 
been the case had we not been focusing as much on pre- 
cise specifications. 

The primary function or a patient monitor is lo transform 
the electrical signals coming from a patient into informa- 
tion that is useful lo clinicians. These electrical signals 
are transformed into streams of digital samples represent- 
ing a wave. This wave is analyzed and a numeric value is 
produced thai represents a piece or the information con- 
tained in the wave, such as heart rate derived from an 
EGG wave, or blood pressure derived from a blood pres- 
sure wave. This numeric value is called a parameter. 

In our case we needed lo analyze three separate EGG 
waves and produce three separate ST measurements. We 
needed lo give the user control over the ST measure- 
ments both as a group (e.g., turn the ST measurement for 
all the ECG waves on or off) and independently ( inea.suie 
the ST only on the second ECti wave). This requirement 
for both separate and combined controls was met through 
the use of a multichannel parameter. The ST parameter 
has three channels (ST1. ST2, ST3), with one ST value fof 
each channel. 

The patient monitor also contains data management soft- 
ware that provides the user with a trend of changes in 
the ST measurements. Depending on the on/off slate of 
the ST parameier and channels. ST values are stored or 
rejected by the data management software. To communi- 
cate this information, the ST software needs to maintain 
Iwo fields in a message, a parameter on/off field and a 
channel on/off field. These Iwo fields were defined as 
Boolean fields within a larger data structure. The 
associated textual description was: 

Parameter ON/OFF- Parameters may be switched off from a central 
task window ... This has no effect on the internal functionality . 

Channel ON/OFF: Channels may be switched on and off, but the 
effect is as with Parameter ON/OFF Processing remains unaffected 

We felt that our introduction lo formal specification 
helped us quickly notice a potential problem, specifically 
the lack of an invariant in this description. IIP-SL sup- 
ports the specification of invariants on data lhal is being 
modeled, ami when used in a dala type definition, an 
invariant defines a relationship that must hold for all 
instances of thai dala type. A quick look al the descrip- 
tion of the dala structure containing the above fields 
shows that there is little discussion of any relationship 
between the parameter on/off fields and the channel on/ 
off fields. 

We expected to see an invariant indicating lhal if the pa- 
rameter was in the off stale then the channel imisl be in 



the off State. The lack of this invariant raised a warning 
Hag. Ii turned out that the dala management software 
received all three channels of ST measurement informa- 
tion, but used only the parameter on/off field lo deter- 
mine whether or not lo store the information. When we 
turned a channel off bill left the parameter on (a reason- 
able scenario from our point of view) the dala manage- 
ment software would display an ST trend with invalid 
data, since no ST measurements were being made while 
the channel was in the off stale. We were able to resolve 
this problem through discussions with the trend software 
developer long before the product was released lo cus- 
loniers. 

Similar ambiguous specification problems were encoun- 
tered in a related area — alarm handling. There was no 
clear description of the expected behavior of multiple 
alarms on multiple channels of a single parameier. As a 
result we developed software thai we thought behaved 
reasonably. After several unsuccessful attempts at making 
our alarm behavior match the expected alarm behavior 
(the behavior of the existing alarm handling software), 

discussions with the alarm software developer again led 

to resolution of Che problem before product release. 

If a description is ambiguous then multiple users of thai 
description can easily have different inlei-prelalions. If a 
developer can provide a single, precise description (a 
model) of what is lo be implemented, then ihere is al 
least an opportunity for the adequacy of the model to be 
lesled through reviews, and ambiguities cleared up al the 
earlier stages of a project. The single, precise model may 
be wrong, but al least multiple reviewers can focus on 
the same wrong model instead of making incorrect as- 
sumptions about an ambiguous model. 

Issues 

Any new process, no matter how great the benefits, will 
encounter some difficulty in gaining acceptance or reach- 
ing the point where the benefits become real and tangi- 
ble. Introducing formal specification is no exception. The 
issues raised fall into two categories: learning and apply- 
ing formal specification, and introducing a new methodol- 
ogy into an exisling software development process. 

Learning and Applying Formal Methods. The issues related to 
this Category included: 
• Differing learning curves for reading versus applying I he 
modeling loots provided by IIP-SL. 

This problem is akin to reading versus speaking a foreign 
language. If the words and syntax have already been put 
together by someone else, it is not difficult to follow 
most of what is wrilten down. It is much more difficult 
to find the correct words and apply (he correct syntax on 
one's own. A similar learning curve must be overcome in 
becoming proficient at creating models using IIP-SL. and 
it involves practice and making mistakes. Mistakes are 
not easy things to figure into a schedule. 

Al the start of this collaboration the AMG gave a one- 
w : eok IIP-SL course lo our project I earn and software 
engineers from other projects. The goal of the course was 
to introduce formal methods and IIP-SL. and lo have all 
participants feel comfortable reading IIP-SL specifications. 
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This goal was reached. After the five-day course most 
participants felt comfortable reading HP-SL. But most also 
felt that more practice was needed to feel comfortable 
writing HP-SL specifications. 

• Wondering if we could get the benefits of formal specifi- 
cation without learning another language or being so for- 
mal. 

This issue was raised frequently by ourselves and others 
during this collaboration. As mentioned earlier, we fell 
that the focus on early problem analysis had both a direct 
and an indirect impact on our development effort. For 
example, the problem discussed earlier in which (he prop- 
erty of measurability was not met was found as a diivri 
result of creating a precise specification. The second 
problem, the ambiguous parameter and channel descrip- 
tions, was quickly noticed as a result of our belter under- 
standing of what it means to create a solid specification. 
Even though we are still in the learning stage, we feel 
that we need to master the use of this rigorous approach 
to software development before we can make the best 
judgments about where added rigor can be most produc- 
tive. 

• Using formal specification techniques to capture the es- 
sential behavior of an exisling software implementation. 

We found it to be very difficult lo use formal notation to 
document the behavior of an exisling implementation and 
felt that it was one of the least productive ways for us to 
make use of formal specification. We attempted this for 
software that was being ported from an exisling product. 
Although this effort did in fact point out an existing prob- 
lem, the resulting specification was not very abstract and 
ended up being focused on behavior that was a result of 
our specific implementation rather than on behavior re- 
sulling from a more abstracl view of the problem. 

• I 'nderslanding where increased formality is appropriate 
and where it is not. 

We found thai deciding where to use formal specification 
was to some extent a judgment call. Our projects are 
typically nol neal, lidy projects in which all of the re- 
quirements are precisely known at the start and each 
software engineer has a clean sheet of paper from which 
to begin development. Many of Ihe medical algorithms 
and associated behaviors (e.g., alarm handling) need lo be 
reimplemented fwith enhancements) in new products, and 
there is often software in anolher product (e.g., data- 
bases, data review screens) thai can be leveraged. 

For example, to create a display for a new measurement 

in the palienl monitor, a developer typically uses existing 
display software as a template, a case in which there 
doesn't appear in be much of an underlying model lo 
capture. On the other hand, we did find that the lime 
spent modeling Ihe notion of measurability was usefiil. 
In this case, there appeared lo be a significanl difference 
between the underlying model and Ihe implementation. 
Our software development efforts are best termed soil- 
ware reengineering, and in this selling, we fee] thai for- 
mal specification needs to be mastered and used as a 
tool at Ihe discretion of the developer. 



Introducing a New Technology. The issues related to this 
category included: 

• The effect on project schedule. 

The use of this level of rigor for software development 
was new to us. and we devoted a lot of effort learning 
how to use formal specification for our tasks At the start 
of the project we scheduled lime for taking an HP-SL 
course and workshop. In addition, we lengthened the pre- 
implemeniation stages of the schedule to account for 
what we thought was the additional lime required to 
learn and apply formal st>ecification. In retrospect, we 
underestimated how much time it would take to get com- 
fortable with this tool and overestimated the numl>er of 
portions of the software task thai we thought we could 
specify. Limiting our efforts lo more manageable-sized 
portions or the task is one way we could have limited the 
potential schedule cosl. 

• The need for up-front commitment of resources. 

On this project, as on mosl of our projects, two very pre- 
cious resources arc time and money. The additional time 
in a project schedule allotted lo learning a new soft ware 
development melhod must be accepted by all parlies. 
Also, the transfer of this technology involved a collabora- 
tion between geographically separated groups. To collabo- 
rate means to work togelher. and this, despite modem 
systems of electronic communication, requires some face- 
to-face time. In our case travel was a necessary part of 
such a collaboration. 

• The difficulties in measuring the benefits of formal speci- 
fication. 

Improvements in software quality can be difficult lo mea- 
sure based on Ihe metrics from a single software project. 
The size of the project, design and code complexity, skill 
sets of the personnel involved, and lime allotted to the 
project can all affect the metrics used to measure the 
benefits of a software process change. 

In Table I the metrics for our project are compared to a 
project of similar complexity. Our metrics were good, 
and. although there are a number of ways to explain the 
dala (e.g., thai defect density is proportional to lest 
hours) we believe that the focus on up-front problem 
analysis encouraged by learning and using a formal nota- 
tion played a significant role in achieving a high-quality 
product. 



Table I 

Comparison of Project Metrics 

Defect 

Project KNCSS* Test Hours Density* 

( iiir Project lli-1 20.3 0.0(5 

Project X 81.8 61,2 0.20 

"thousands ol noncomment source statements. 
"Delects pet KNCSS 
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Conclusion 

Many challenges must be faced in a collaboration to 
introduce a new methodology into an existing software 
development process. The biggesl change we would make 
is to have all parlies view the collaboration as pari of the 
project, not something extra that can be done if lime per- 
mits. Only one schedule should exist and it should in- 
clude allowances for the collaboration. Only if the effort 
is given this importance and support can the people in- 
volved make it a true success. 

We used this collaboration as a vehicle for learning more 
about the benefits and costs of using formal specification. 
In practice it was very difficult to balance the introduc- 
lion of a new method with Ihe need to produce a rela- 
tively simple software enhancemenl in a short amount of 
time. We are convinced that there is much to be gained 
by using a formal specification language like BP-SL to 
capture the essential behavior of Ihe software machines 
that we design and build, and are continuing to use this 
methodology in our development efforts. 



Acknowledgments 

We gratefully acknowledge Ihe continued support and 
contributions from Fran Midland. George Dillcr, and Wolf- 
gang Krull from Ill's Wall ham Division, and Mike Diss, 
Sally Jubb, Tony Rush, Paul Marry, and Ray Crispin from 
IIP Laboratories in Bristol. England. 

Bibliography 

L J. Woodcock and M. Loonies, Software Engineering HaOiemal- 
ics. Addison-Wcsloy. 11188. 

2. T. Rush, el al. Cam' Studies in lll'-Sl.. Software Engineering De- 
partment, BP Laboratories Bristol, I1PL-90-137. August 1990. 

3. G. B. Jones. Systematic Software Development I 'simj VDM. Pren- 
lict-Hall International. 1986, 

4. A. Davis, Software Requirements Analysis & Specification. Pren- 
tice-Hall Inc., 'l!l!K). 

5. T. Denvir. httmttuction In Discrete Mathematics for Soft irnrc 
Eiiaiaecrinu, MacMillan Education Ltd., 1986. 

(1. D. Garlan and N. Delisle, "Formal Specifications as Reusable 
Frameworks," Lecture Notes in Computer Science, Vol. 428, Spring- 
er-Verlag 1990. 



50 Decetnber-1991 Howleii-I'.-irkard Journal 

©Copr. 1949-1998 Hewlett-Packard Co. 



Formal Specification and Structured 
Design in Software Development 



HP-SL history specifications and techniques from structured analysis are 
used to create a formal specification for a critical portion of the code for a 
medical instrument. 

by Judith L. Cyrus, J. Daren Bledsoe, and Paul D. Harry 



The cardiology business unit at I IPs McMinnville Division 

is responsible for producing medical instruments, some or 

which have lire-c rilical functionality and require a high 
degree of reliability. These instruments are used in a high- 
tension environment by medical personnel who are not 
necessarily computer literate and do not use the instru- 
ments on a daily basis. Our project team (from the car- 
diology business unit) is responsible for the development 

of one of these life-critical instruments. 

Previous generations of the product are viewed as having 
defect-free software, but there is no formal way to verify 
this belief. The code in these earlier instruments was 
written in assembly language and is tightly coupled with 
the hardware. Also, the code is considered t" be hard to 
understand and is not reusable. To remedy this situation 
we established the following goals for the new software 
in the product: 

• Produce defect -free, safety-critical software with fewer 

debug cycles 

• Create Software that can be reused in the current product 
family and in future products 

• Write unambiguous documentation that describes the 
safely-critical functionality of the product 

• Perform a validation process that Compares the imple- 
mentation against the specification 

• Meet or exceed regulatory requirements for safety-critical 
pn iducl-s. 

This paper ilescribes our experiences with using formal 
specification techniques to help implement a safety-criti- 
cal portion of the embedded software system for the 
instrument. 

WHS Formal Methods? 

Daring ftie project Investigation stage, formal methods 

were seen as an aid toward meeting our software goals. 
We were convinced thai we should use the best available 
methods to achieve the high reliability needed for our 
product. We also saw formal specification as a way to 
ensure that product requirements were well-understood 
by our current project team and by future development 
learns or mainlainers. The applied methods group (AMG) 
from HP'S Bristol laboratories provided us with informa- 
tion about their work with a formal specification language 

c alled iipsi. (HP Specification Language) and offered to 

collaborate with us on the project. We saw the collabora- 



tion as a way to establish expertise in formal methods 
within our division. 

The AMG had previously collaborated with another group 
at our division to use formal notation for a small part of 
the software for an another product. Although this was 
done on a very small scale with limited success, there 
was enough positive impact to influence management 
approval for our decision to use formal methods. This 
was a critical factor in successfully using formal methods 
because we fell that we needed to include time in the 
project schedule for using formal specification techniques. 

After deciding 'hat we wanted to use formal methods in 
our development process, the first thing we did was to 
establish a collaboration plan between the IIP McMinn- 
viDe project team and the consultants from the AMG in 
Bristol; This plan defined the roles of the collaboration 
team members and established a modified product life 
cycle plan that provided for the anticipated Front-end 
loading on the project schedule. One MeMinnville engi- 
neer and one AMG engineer actively engaged in the safe- 
ty-critical software development effort. Other collabora- 
tion team members participated in support activities, 
primarily serving as reviewers. 

The Formal Specification 

The team decided that it would be loo ambitious to at- 
tempt to specify the entire software system formally. 
Therefore, the system functionality was divided into safe- 
ty-Critical and nonsafeiy-critical subsystems, l-'ig. 1 illus- 
trates this division. The safety-critical code is located in 
the safety critical controller and occupies about 16K bytes 
of ROM. 

Based primarily on the product's external specification 
(KS).* the collaboration team produced a complete formal 
specification of the safety-critical part of the software. 
The formal specification provided a process model of the 
system, specifying the relationship of inputs and outputs 
over lime. This model uses the 1 IP-SI. history specifica- 
tion (see artic le on page 10), which associate's data values 
with lime, thereby capturing timing constraints and speci- 
fying a data object's value for all lime. This allows com- 
parisons between data objects at any particular time, and 

"ThO Mini speoficatiun is ii natural language description of the pioduci rciiunements 
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Fig. L System architecture showing the separation between safety- 
critieal and nonsafi'ly-rriliial functionality. 

provides a history of what has happened before so that 
new data values ran he derived from previous values. 

'Hie specifiealion is illuslraled by a varianl of data flow 
diagrams. These diagrams look much like traditional 
slruclured analysis daia flow diagrams. 1 - but the mean- 
ing of some of the symbols is changed to belter illustrate 
the formal specification. An example of one of these dia- 
grams is shown in Fig. 2. The data Hows between pro- 
cesses correspond to HP-SL histories, and the dashed 
lines, which indicate control data in traditional structured 
analysis data flow diagrams, are used to indicate optional 
data which is only present in some produci family mem- 
bers. 



Early in the project, we decided to use t wo views of data 
to support a need for concreteness at the external level 
and abstraction at an internal level. The external view 
represents hardware dependencies such as the register 
bits that hold voltage information. The internal view pro- 
vides a hardware independent representation of data — for 
example, a data structure that just holds voltage values 
regardless of the source or destination. The internal view, 
or core, specifies instrument functionality that is common 
to all of our product family members. This two-level view 
allowed us to separate and more abstractly specify the 
core of the system in a way that isolates it from the im- 
pact of hardware changes and makes it easier to reuse. 
Specifying the external view in a concrete way enabled 
us to correlate our design with the hardware design spec- 
ification. 

The formal specification includes an HP-SL data model of 
the external and internal views, HP-SL conversion pro- 
cesses which specify how the internal view of the data is 
derived from the external view, and a complete HP-SL 
specification of the system core process. The simplified 
top-level data llow diagram shown in Fig. 2 shows this 
data view and the conversion processes that convert from 
the external view lo the abstract internal view. Data flows 
(histories) coming into and going out of the diagram 
around the edges illustrate external interfaces. The six 
bubbles around the outside illustrate the conversion pro- 
cesses with the internal data flowing into and out of the 
core process. 

A preliminary foimal review raised many requirement 
issues. Initially we thought that the product's external 
specification would be a sufficient source on which to 
base the foimal specification. It turned out that this left 
many requirement issues ambiguous or undefined and did 
not provide enough information about the hardware and 
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timing to complete the specification. Following the pre- 
liminary review, project team members were asked to 
provide timing diagrams and hardware and software inter- 
face documents, which would otherwise have been re- 
quired later in the project. Only when Ihese were avail- 
able could the formal specification be completed. 

Implementation Route 

One of the major benefits of using an HP-SL specification 
Structured as a data flow diagram is that the traditional 
route from structured analysis to structured design can. 
with modifications, be used. The data flow diagrams that 
illustrate the HP-SL specification drive the basic layout of 
structure charts. 

Fig. 3 provides a simplified comparison between portions 
of the traditional structured analysis to structured design 
implementation route and the formal process Specification 
implementation route. In both approaches the process 
specifications define the system requirements and the 
module specifications define the design and implementa- 
tion of the system. 

In the traditional approach, informal process specifica- 
tions define primitive processes (processes that are not 
decomposed into further processes). Composite processes, 
and ultimately entire systems are defined by combining 
the primitive processes according to the data flow dia- 
grams. Module specifications describe the functionality of 
the individual routines that implement the system. 

In the IIP-SL approach, a process specification is a pre- 
cise description of the transfonnat ion of incoming data 
into outgoing data. The modified data How diagrams de- 
fine how the process specifications are combined to form 
the process specifications of higher-level processes. As in 
the traditional approach, module specifications define the 
implementation routines. 

This systematic development route preserves iraccabilily 
between modules of the implementation and processes of 
the specification. Traccabilily permits verification of the 
implementation against the specification, and also allows 
test plan designers to make the best use of the specifica- 
tion in defining test cases. The following steps are taken 
to implement this systematic development route. 

1. Start with an HP-SL specification and the accompany- 
ing data How diagram. Fig. 4 shows the data flow dia- 
gram for one of the subsystems in the product. Remem- 
ber, dashed lines indicate optional data flows. wlueh exist 
only in systems that have this option installed. 

2. Treating the data How diagram from step 1 as a classi- 
cal Structured analysis data flow diagram, transform it 
into a hierarchical structure chart. Fig. "> illustrates a 
structure chart for the example process. In this example, 
the second-level modules correspond to the processes of 
the data flow diagram, except for the process derive_op- 
tionjailure. which hits been moved to a lower level for a 
more efficient implementation. The data couples shown in 
Pig. 5 represent entire histories. 

13. No implementation can afford to pass entire histories 
between modules. A reduced design must be produced in 
which each history is replaced by just the current value. 
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option lailure 



Fig. 4. Data flow diagram for example subsystem. 

Any historical information required must be explicitly 
stored in local stores (see the hexagon-shaped boxes in 
Fig. fi). Notice that two local stores have been added to 
module time^pulse. One keeps track of the time since the 
last pulse was fired and the other keeps track of the time 
since the last external pulse was delected. 



4. The Structure Char) is optimized. For example, modules 
are moved to different levels in the hierarchy (see the 
reduced structure chart in Fig. 3b). 

5. If necessary, produce module specifications. Many 
times modules are closely related to the process Specifi- 
cations, thus eliminating the need for module specifica- 
tions because the process specifications are sufficient. 
However, if the optimization performed in step 4 is exten- 
sive, optional module specifications may be required (see 
Fig. 3b). 

6. Code is written from the structure charts, the HP-SL 
process specifications, and if any were generated, the 
optional module specifications. 

Implementing a Process Specification 

The data flow diagrams and structure charts shown in 
Figs. 4. 5, and (> provide a graphical representation of the 
software being developed using the formal implementation 
steps described above. This section describes the develop- 
ment of the IIP-SL process specification for the process 
time_pulse, and the module that implements this process 
(labeled time_pulse_m in Fig. f>). The history and event 
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specifications described in the article on page 40 are used 
to develop the HP-SL specification for this module. 

Pulses. Before considering the time_pulse process, we first 
consider pulses and the definition of an overdue pulse. A 
pulse is a dataless event occurring within a specified time 
interval. A dataless or single-valued item can be modeled 
by the type Unit Pulses can then !«■ modeled by an event 
history of units. 

syntype Pulse* = HistelUnrtl 

If we have a history pulse„ of type Pulse h . we can test a 
pulse at time t with the expression pulseh @? t, which is 
true if and only if a pulse occurred at t. 

A pulse is overdue if, from some lime t_ start to the cur- 
rent time now. there have been no pulses, and the system 
has been in state running. This is formalized by the expres- 
sion. 

( V t sat t_start st \ t < now • 
i pulsen ®' ' 

A 

state,, @ t = running 

) 

The time t_start is tire_tnterval_rnsecs (lime between pulses) 
earlier than current time, or t_start = now - firejnter- 
val.msecs. 



As in the raise_aiarm process (see article on page 40}. we 
must consider the behavior just after startup. w"hen now < 
firejnterval_rnsecs a pulse cannot be overdue. This behavior 
can be specified by an existential quantifier. 3 (exists), 
which tests whether t_start is earlier than the startup time. 
Combining the test for an overdue pulse with the test to 
verify that t .start is earlier than the startup time, we get: 

In pulse_overdue. Hisu, Pulse x Hists State — Bool 

is pulse.overduel pulse*, state- I 

A 

let 

val now ^ end s lstateh) 

val start.time t start s (statet,) 

val firejnterval_msecs ^ 1000 / rate h @ now 

in 

(3 t_start = now - fire_interval_rnsecs sat t_start > 
start_time • 

(V t sat t_start < t a t < now • 
-(pulse h @? t) 

A 

state h @ t = running 

) 



which returns a TRUE value when a pulse is overdue. 
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Time Pulse Process. The time_pulse process generates 
pillSes, and there are two pulse generation modes: de- 
ferred and fixed. In fixed mode pulses are generated peri- 
odic-ally attd in deferred mode pulses are generated only 
if an external source of pulses has failed. The process 
has four Inputs: system state, pulse mode, the required 
rate of pulse generation (which determines the pulse in- 
terval), and the external pulses. There is one output — 
pulses generated when a pulse is overdue in either mode. 

The process specification for time_pulse is of the form: 

rein time_pulse: 

(Hist 5 State x Hist s Mode X Hist s Rate * Hist e Pulse) x 
|Hist e Pulse) 

is time_pulsel (stated, modeh, rate,,, externaLpulsei,), pulsed 
A 

The occurrence of an output pulse can be detected by 
the expression pulse_h @? now. However, we want lo base 
pulse generation not only on when an output pulse oc- 
curs, but also when the pulse does not occur. This can be 
achieved with the operator », read as "if and only if." 

In fixed mode, an output pulse is generated if and only if 
there has been no output pulse for more than a given 
time, that is. if the output pulse is overdue. This properly 
can be formalized by the expression: 

pulse,, @? now 

pulse_overdue(pulse h , stated) 

En deferred mode, there is an additional constraint. Not 
only must there have been no output pulse, but there 
must also have been no external pulse. 

pulse_h @? now 

(pulse_overdue(pulse h , state h | a pulse_overdue(external_pulse h , 
state h )) 

Which test applies depends on the current mode (mode h @ 
now). 

Process Specification. The following is the final specifica- 
tion for the time_pulse process. 

I: rein time_pulse: 

2: (Hist s State x Hist 5 Mode X Hist s Rate x Hist e Pulse) x 
3: (Hist e Pulse) 

4; is time_pulse( (state,,, mode,,, rateh, externaLpulse,,), pulse,,) 

5: | 

6: let val now g end s (state,,) 

7: In 

8: pulse,, @? now «* 



9: cases mode,, @ now of 

10- case J fixed J then 

II; pulse_overdue(pulse,,, state,,) 

12 case J deferred ] then 

13: pulse_overdue(pulse,,, stateh) 

14: pulse_overdue(externaLpulse,,, state,,) 

15: endcases 



IB: endlet 

This relation specifies that a pulse occurs (line 8) in fixed 
mode (line 10) if the interval since the previous generated 
pulse (line 11) reaches the interval determined by the 



rate setting in I he pulse_overdue function. A pulse occurs in 
deferred mode (line 12) if both the interval since the pre- 
vious generated pulse (line 13), and the interval since the 
previous external pulse (line 14) reach the interval deter- 
mined by the rate setting in the pulse_overdue function. 

The test for mode and overdue pulses (lines 9-15) can be 
rewritten as: 

pulse overduelpulseh. stateh) 

a (mode,, @ now * deferred v pulse_overdue(externaLpulseh, 
state h ) I 

In the C code implementation described below, this deci- 
sion structure is used directly on lines 25 to 30. 

Implementation. The following is the C code for imple- 
menting the time_pulse function. 

1: include "ic_global.h" 

2: typedef enum | PULSE, N0_PULSE } type.pulse ; 

3: typedef enum ( FIXED, DEFERRED ) type_option_mode, 

4: typedef enum ( RUNNING, STOPPED ) type_option_state; 

5: extern unsigned_16 rate_table||; 

6: type_pulse time_pulselexternaLpulse, mode, state, rate ) 

7: type_pulse externaLpulse: 

8: type_option_state state; 

9: type_option_mode mode; 
10: unslgned_8 rate; 
11. ( /**" Begin Function ***/ 

12; static unsigned_16 externaLpulse_h_timer; 
13: static unsigned_16 pulse_hjimer; 
14: type_pulse pulse; 

15: 1' Reset the timers whenever the option is not running."/ 

16: Thai way the timers will never expire and no pulses will be fired*/ 

17: if (state != RUNNINGl 

18: | 

19: externaLpulse_h_timer = 0; 
20: pulse_h_timer = 0; 
21: pulse = N0_PULSE; 
22: ) 

23: else /* option is running "/ 
24: ( 

25: pulse = (( pulse_h_timer >= rate_table|rate|) /* pulse overdue */ 

26: && I* and if not in deferred mode*/ 

27- (I mode 1= DEFERRED) f the ext. pulse must also be overdue 

*/ 

28: II |externaLpulse_h_timer >= rate_table|rate|)l 
29: ? PULSE 
30: : N0_PULSE; 

31: if (pulse ^ PULSE) pulse_h_timer = 0; 
32: else if lpulse_h_timer <= rate_table|rate:l pulse_h_timer++; 
33: if (externaLpulse ^ PULSEI external_pulse_h_timer = 0; 
34: else if (externaLpulse_h_timer <= rate_table|rate|) 
external_pulse_h_ timer++; 

35 ) /" end option is running 7 

36 return(pulse); 

37 ) 

The two calls to pulse_overdue are replaced by two timers. 
externaLpulse_h_timer and pulsejijimer (lines 1!) and 20). 
They are reset to zero whenever the state Ls no longer 
miming (lines 17 to 22), or the corresponding pulse oc- 
curs (lines .'11 and Wj, Otherwise they are incremented 
( lines :12 and :54 ). 
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In the specification world we typically do not worry 
about size limits. However in an implementation, size lim- 
its are critical. If we repeatedly increment the timers they 
could overflow. Fortunately we are not interested in how- 
big the timers get once they are beyond the overdue time. 
Thus the code stops incrementing the timers once they 
reach the rate table limit (lines 32 and 34). 

Impact on Project 

The decision to use a formal notation for the safety-criti- 
cal software had a major impact on the project schedule 
and the way in which we performed our implementation. 
Because of the learning curve we found that front-end 
loading the project schedule was necessary to use formal 
methods successfully for the first time. In our case the 
steep learning curve was offset by support from the HP 
Bristol team. Thus, the overall impact on the schedule 
turned out to be minor. The benefits of a more complete 
external specification (ES). early requirements decisions, 
complete interface specification, and a good software 
design paid back the time needed to produce the formal 
specification. In fact, the completeness of design made it 
possible for one engineer to code the entire safety-critical 
subsystem in less than the usual amount of time required 
to complete a subsystem of this type. 

The impact formal specification had on our implementa- 
tion is that it enabled us to identify and deal with prob- 
lem areas early in the project, contributing both to the 
quality of the final external specification and to hardware 
design decisions. Specific areas of this impact include: 
To isolate the safely-critical software, we decided to use 
separate microcontrollers for safety-critical and nonsafe- 
ty-eritieal tasks. 

The formal specification affected the structure and con- 
tent of the ES. It exposed ES ambiguities and incomplete 
product definition. For example, the ES described normal 
system functionality, but did not define system behavior 
during abnormal situations, such as when multiple keys 
are pressed simultaneously. The specification Forced us 
to deal with these issues. 

Problem areas in the formal Specification identified the 
need for additional documenlation (timing diagrams and 
hardware/software interface documents) early in the 
project A liming issue thai was mentioned in general 
terms in the ES was exposed by (he specification as a 
hazard. These timing problems had to be belter under- 
stood before Ihe specification could be finished. 
The need lo make firm requirements decisions Tor writing 
a forma] specification that could be reused in follow-on 
products encouraged early definition of possible future 
systems and peripheral interfaces. 

Work on the formal specification helped new team mem- 
bers learn the product requirements by exposing areas of 
misunderstanding or ambiguity. 

The formal specification identified important lest cases 
and boundary conditions. Some processes have precondi- 
tions Of Invariants thai define corner cases, which bad to 
be lesled. 

The formal specification helped in dealing with the regu- 
lalory process by helping define and plan for potential 
hazards (e.g., interprocess communication failure). 
Software changes resulting from late hardware changes 
wen cus.v lo make and document. 



• The goal of maximizing code reusibility for the safety-crit- 
ical software was achieved. 

Problem Areas 

We did encounter a few problems during development. 
These can be classified as problems associated with the 
project development process and problems associated 
with using formal methods. 

Problems we found associated the development process 
were: 

• The external specification has a dual role in our division. 
It serves both as the natural language requirements docu- 
ment and as an input to the business decision at the in- 
vestigation-to-implementation checkpoint meeting. This 
typically results in an ES that is not optimally suited to 
either, and in many cases does not contain sufficient de- 
tail on which to base the formal specification. This prob- 
lem can be solved by producing, in addition lo the busi- 
ness-needs-driven ES. a software requirements document 
that addresses functionality details, timing requirements, 
and hardware and software boundaries. 

• Some interfaces were not tied down for a long time. This 
meant the formal specification for the interfaces had to 
wait, and sometimes this meant changing the core pro- 
cess when the interface was finally understood. 

• The need for a concrete definition of the boundaries and 
interfaces when specifying only a part of the system was 
not init ially recognized. Early availability of interface 
requirements would have greatly simplified the specifica- 
tion process. 

Problems we encountered with using formal methods 
were: 

• When we learned HP-SL, we learned notalion. but not 
abstraction or modeling. Il is very hard to slop thinking in 
programming terms. A better grasp of abstraction would 
have helped in gelling the mosl benefit from Ihe modeling 
power of formal notation. This comes with practice. 

• Clever parts of ihe HI'-Sl, specification were intellectually 
pleasing but not understandable by other members of the 
leant or reviewers. 

• Formal notation does not prov ide early estimates of code 
size and execution performance, This means thai gross 
estimations (guesses) were used for ROM and RAM re- 
quirements — decisions that were needed early in the proj- 
ect As il turned out. these estimations were remarkably 
accurate. 

Conclusion 

A number of factors were vital to Ihe successful comple- 
tion of the formal Specification and its usefulness in our 
software development. The mosl critical factor was lhat 
the decision to use formal notation was made early in ihe 
project. Experience on other projects has shown that ret- 
rofitting abstractions Into an existing producl implementa- 
tion is not very successful. A lale decision would also 
have reduced the positive impact Ihe process had on the 
external specification document. There were several key 
factors Ilia! contributed to our success with formal speci- 
fication. Some of these include: 

• The collaboration with IIP Labs was crucial. The ill* I^ah 
team from Bristol spent some time with us lo begin Ihe 
Specification and their participation in the product's HP- 
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SL review, which included bolh the hardware and soft- 
ware engineers from McMinnville, provided necessary 
I IP-SI, expert ise. 

• The diagrammatic overview of the specification provided 
both a visual way to see how the parts of the specifica- 
tion fit together and a more traditional view of the soft- 
ware which > s useful when working with non-MP-SL read- 
ers. 

• The division of the specification into an abstract reusable 
core arid a less abstract, customized interface, saved re- 
writing the entire specification when hardware changes 
were made. 

• The implementation route paralleling traditional ap- 
proaches helped reduce the negative impact of introduc- 
ing a new development process. 



Formal specification has often driven the capture of prod- 
uct requirements and product design. Even hardware de- 
sign has been influenced. The safety-critical nature of our 
product steered us to use a formal notation. However, the 
influences of the process on our project demonstrate that 
it provides benefits which are helpful to any project, and 
not just safety-critical projects. 
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Telecommunications Network 
Monitoring System 



This system supervises any telephone network using the 2-Mbit/s CEPT 
primary rate interface and the CCITT R2 or #7 signaling system. It 
automatically collects and analyzes data on CCITT-specified and other 
parameters related to the calls flowing through the network nodes 

by Nicola De Bello. Giuseppe Mazzucato, Antonio Posenato, and Marco Silvestri 



Telecommunication networks need to be monitored for 
several reasons. First, for planning purposes, the network 
manager has lo identify the most effective locations for 
investment in new resources. To do this the manager 
needs to know the network areas where the traffic is 
most critical and the quality of seivice is low. Monitoring 
is also done to certify lite quality level of the network as 
seen by normal users and, more often, by managers re- 
sponsible for other connected networks. The third reason 
for monitoring is to identify faults and verify the behavior 
of Ihe network in critical situations. All of these reasons 
are growing in importance, while telephone networks are 
becoming more complex and geographically extensive. 

Network behavior is monitored by measuring some pa- 
rameters related lo the calls llowing through the network 
nodes. These parameters, in part specified by Ihe CCJTT, 
provide informal ion on several aspects of network Status. 
Some parameters, such as the number of telephone calls 
and EhSir mean duration, are related to the traffic intensi 
ty and type. Others, such as the number of calls resulting 
in a congestion signal, provide a measurement of Ihe 
quality of service offered by Ihe network. The parameter 
most commonly used for this purpose is tlie answer-sei- 
zure ratio (ASR), defined as Ihe ratio between Ihe num- 
ber of successful calls (answers) and the total number Of 
call attempts (seizures). This ratio represents Ihe proba- 
bility that a user will be able to complete a call on arty 
given attempt. Other parameters are related to network 
efficiency and use. In any case, to understand network 
behavior fully, it is very important to calculate the param- 
eters separately for each of the paths in the network dur- 
ing the time of interest 

Monitoring System Requirements 

Parameter measurements have to be made using instru- 
ments distributed throughout the network of interest. 
Then, to analyze the network from a global point of view. 
Ihe raw data has to be correlated with network topology 
information. 

Some network elements contain embedded instrumenta- 
tion for monitoring, but ii is difficult to use this informa- 
tion for monitoring all of the network. In fact, the ele- 
ments of a telephone network are usually made by 



different manufacturers using various technologies, so the 
performance information that can be gathered is not ho- 
mogeneous. .Another point to note is that monitoring is 
not the main function of the network elements, so when 
one of them becomes busy performing its main function, 
it usually means that the measurements must be halted. 

A monitoring system has to be very flexible. In fact, there 
are several different types of networks, from small private 
networks to large public ones, from local access net- 
works to those covering very wide areas. Every network 
has its own problems to solve and every organization has 
its own way of resolving them. Also, inside an organiza- 
tion, there are several departments interested in different 
aspects of network behavior. A system for telephone net- 
work monitoring has to be adaptable to meet all of these 
sit tial ions. 

Telephone networks are always evolving to meet their 
users' needs. It is therefore impoilanl that the monitoring 
system be able to grow with the network. 

Monitoring is a distributed process, so it is more efficient 
to perform a greater pari of (he processing where the 
data is collected than lo centralize the data for process- 
ing. This improves data transmission efficiency and the 
scalability of the system. The distributed approach also 
ensures uniform quality and formal of the data across the 
whole network irrespective of network element types. 

System Architecture 

The HP E3500A network monitoring system, shown in 
Fig. I, is composed of two main parts: 

• Peripheral units, which are connected I" the network and 
collect the daUl 

• A central unit, which is a processing system that elabo- 
rates the data and provides a user interface to the sys- 
tem. 

The IIP E3600A network monitoring system is applicable 
to networks using the CCITT R2 and CCITT #7 signaling 
systems ami Ihe ('KIT 2-Mbit/s primary rale interface. 
The peripheral units collect the data related to the net- 
work behavior by analyzing the 2-Mbit/s streams used lo 
conned ihe network switching elements. This monitoring 
point has been chosen because it is a logical border be- 



© Copr. 1949-1998 Hewlett-Packard Co. 



I lei'cmbi'r IWII HewlcH-Pnrkunl Journal 59 



RS-485 serial bus and the ISO 1745 multipoint communi- 
cation protocol. 




WS = Workstations or Terminals 
PU a Peripheral Units 



Fig. L HP E3500A network monitoring system architecture. Thp 
central unit is an HP 9000 Scries 300. 400. or 800 computer. There 
are typically 2 to 6 users. The network symbols on the lower layer 
represent local anil transit exchanges. 

tween the "active" elements and il provide an external 
view of the network that is similar to the user's point of 
view. In addition, the 2-.\1bil/'s PCM digital link has been 
accepted as a standard in Europe and in many other 
countries around the world so there are fewer interfacing 
problems. 

The peripheral unit analyzes the information on Ihe digilal 
link by monitoring the telephone calls flowing in the link. 
The peripheral unil stores a database record for each 
telephone call observed. This record contains all Ihe in- 
formation about the call lhat is required for calculation of 
the call parameters mentioned above. The simplified call 
record format is shown in Fig. 2. To perform ils .job. the 
peripheral needs to capture the signaling messages sent 
by the exchanges in both directions and recognize the 
service tones sent to Ihe user. There are several interna- 
lional standard signaling systems and a number of coun- 
Iry-speeific and vendor-specific versions of these stan- 
dards. The peripheral urdfs hardware and software were 
designed to be able to work with different standards and 
make the actual signaling system used transparent lo the 
Upper levels. The data format is almost independent of 
the signaling system in use so il is easy to integrate the 
data coming from the different links. 

The peripheral units are distributed around the network 
and are connected to the central unit using, typically, 
leased lines and modems. In the case of peripheral units 
located near the computer il is possible to make the con- 
ned ion using an RS-232 cable. If leased lines are nol 
available it is also possible to use switched lines. To mini- 
mize the number of lines used to communicate with pe- 
ripherals, several peripheral units can be connected to- 
gether and managed by the central unit using a single 
communication line. Interconnection and control of the 
peripherals conned ed in litis way are realized using ihe 



Peripheral unit operations are completely controlled by 
the cenlral unit. The central unil bootstraps the peripheral 
units wilh Ihe appropriate application program, sends 
measurement commands, and monitors peripheral unit 
status. In general, the system manager can manage the 
measurement system completely from any of ihe termi- 
nals attached to the central unil. For maintenance pur- 
poses, a portable operator terminal is also available 
which can be connected locally to the peripheral unit. 

Peripheral Unit 

The number of PCM links to be monitored at each loca- 
tion depends on the organization of the network. Addi- 
tionally, different signaling systems can coexisl at the 
same measurement site, and particular functions may be 
required only at certain network nodes. 

These facts led to a modular architecture for the periph- 
eral unit, in which the required special functions are per- 
formed by optional boards. Speech signal processing is 
performed digitally lo ensure a high degree of flexibility. 

The peripheral unit is a multiprocessor device organized 
in a master-slave architecture, As Fig. :J shows, Ihe pe- 
ripheral unit is divided into independent measurement 
modules controlled by ;i master board. The number Of 
slave modules to be installed depends on user needs and 
net work needs. 

Master CPU 

The master CPU is a general-purpose Motorola (iSOOO- 
based CPU board, largely configurable by means of pro- 
grammable logic devices (PLD). The CPU has 512K bytes 
of RAM expandable lo 2M bytes. 64K bytes of EPROM 
expandable lo 512K bytes. 2K bytes of EEPROM, and a 
number Of peripheral chips such as programmable Input/ 
oiiipul potts, serial communication controllers, and tim- 
ers. The master CPU controls between one and lour slave 



Signaling Code 
Time 
Flags 
Circuit Number 
Seizure Duration 
Dialing Duration 
Anomaly Code 
Recognized Tones 
Charge Pulses 
Charge Rate 
Dialing 



Fig. 2. Simplified Call record format. The flags Delil shows the status 
of tin- seizure signal, answer signal, and answer complete fags. 
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modules through the system bus which includes data, 
address, interrupt, reset, monitoring, and control signals. 

The master and slave CPUs are obtained from the same 
CPU board configured in different ways. 

The inlerprocessor link is based on dual-port RAMs which 
are located on the slave CPU boards. These special com- 
ponents simplify the interface circuitry and allow rapid 
exchanges of large amounts of data with reduced inter 
processor overhead. 

The master CPU manages all the slave modules in the 
peripheral unit by: 
i Bootstrapping 

• Managing commands between the central unit and each 
slave module 

• Managing messages between different slave modules 
(relay function) 

i Uploading measurement data from each slave module to 
the central unit. 

All communications with the central unit, whether via the 
communication board or the internal modem, are con- 
trolled by the master CPU. This allows the slave GPUs l<> 
focus on data Collection and reduce the Overhead for 
communication tasks. 

In addition, the master C PU controls the portable opera- 
tor interlace, a simplified RS-232 interface which is used 
with a portable PC during installation operations or local 
diagnosis of the peripheral unit. 

Slave Module 

Bach steve module consists Of a CPU board named the 
slave CPU. a PCM interface board, and an optional digital 
signal processing board. 

The CPU board controls the other two boards via a local 
bus similar to 1 1 it* one used by the master CPU, using a 
master-slave concept. A highspeed dedicated bus con- 
nects the PCM interface board and the digital signal pro- 
cessing board. 



Depending on the user needs, each module can be re- 
motely and independently configured. Moreover, the user 
can change the configuration at any time because all the 
application programs are located in RAM and boot- 
strapped during system startup. 

Each slave module is able to: 
» Monitor one 4-wire, 2-Mbit/s PCM link 

• Detect frame and mulliframe P( 'M alarms. 

» Analyze channel associated signaling (CAS) systems with 
pulse dialing.* This is performed simultaneously on all 30 
channels in the stream. 

» Analyze CAS systems with multifrequcncy dialing. The 
part of the signaling located in the signaling time slot is 
analyzed fully ( 100% coverage at the busiest times), 
whereas the in-chaiuiel niullifrequency signaling is simul- 
taneously inspected on up to 4 channels (corresponding 
to 97% coverage at the busiest limes). This provides a 
good compromise between measurement performance 
and cost. 

■ Analyze common channel signaling (CCS) systems com- 
patible with ('('ITT Signaling System #7 up to layer 2.* 

• Detect service tones (such as ringing tone, busy tone and 
so on ). 

The main data collection functions of the module are pro- 
vided by the PCM interface board under control of the 
slave CPU When required, analysis of multifrequeney 
signaling in the voice channels is performed by the digital 
signal processing board. 

The PCM interface board consists of three basic parts: 
the PCM inlet lace, the PCM stream memories, and the 
digital signal processing unit for signaling channel analy- 
sis. The PCM interface manages the two 2-Mbit/s PCM 
signals, which are in compliance with CEPT standards. 
The signals are decoded and synchronized before the 
frame octets are stored in memory. 

"Application depends on ihe loaded software 



Portable Operator loterface 



Slave Module t 




Fig. :i. Peripheral unit architec- 
ture 
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Depending on the signaling system in use and the slave 
CPU sellings, the 64-kbit/s data stream that is used Tor 
common channel signaling is extracted from each PCM 
stream. 

The typical PCM alarms such as loss of incoming signal 
(LIS), loss of frame alignment (LFA). alarm Indication sig- 
nal (AIS), and others are delected, sampled, and stored in 
such a way that the events are recorded with the best 
accuracy and resolution in terms of Iheir duration, for 
instance, 250 us for AIS. The alarm circuitry is capable of 
revealing a loss of incoming signals with durations of 
only a few microseconds. 

It is important to record these PCM alarms 10 be able to 
correlale service failures with the quality of the physical 
link. 

Application-specific integrated circuit (ASIC) chips were 
developed to generate Control and synchronization signals. 
These help increase reliability, reduce cost, and save 
board space. 

The PCM Stream memories consist of dual-port RAMs 
that are used for temporary storage of the PCM frame 
octets which appear every two milliseconds. When re- 
quired, these 16-hyte packets are transferred lo the ('PC 
ami digital signal processing units for full her processing. 
Special circuits are dedicated lo controlling the data rout- 
ing between the memories and the processing units. To 
reduce ( PC loading, these circuits are responsible for 
downloading the PCM data packets to the selected digital 
signal processing unit and only need lo be stalled by Ihe 
CPU. 

The digilal signal processing unit, based on a Texas In- 
stallments TMS.'J20C10 processor working with a 20-MHz 
clock, processes the A-Iaw-coded* byles downloaded from 
the dual-port RAMs into FIFO chips. The use of FIFOs 
speeds up inlerface operations and simplifies Ihe circuitry. 

Use of digital processing allows complex and lime-inde- 
pendent analysis, flexibility, and multiplexing, In addition. 
Ihe application programs used by Ihe PCM inlerface are 
loaded in RAM and can be changed at any lime by the 
CPU depending on user needs. 

The digital signal processing unit implements up lo 16 
service lone detectors (425-Hz tones) using reliable digital 
filtering techniques. 

The PCM inlerface board offers a powerful self-test capa- 
bility to detect hardware failures or malfunctions. For 
example, an on board generated signal can be substituted 
for Ihe external PCM signal: this signal simulates all the 
frame alarms and tests Ihe specialized PCM c ircuits. 

The slave CPU selects the operating mode of the mod- 
ule's boards and. after processing the signaling data, ex- 
tracts information concerning telephone traffic. In the 
case of channel associated signaling, it analyzes the sig- 
naling lime slot information (usually extracted from lime 
slot 16), which is stored in the dual-port RAMs, and the 

"During analog-to-digital conversion ot a voice signal, A-law encoding logarithmically 
compresses the l?-t»t value resulting from uniform quantization into an B-blt word The A 
law is recommended tjy thfl CCIT7 and is used in all countries except North America and 
Japan, where the u law is used 



digital signal processing results. For common-channel sig- 
naling, a Iwo-channel serial communication controller 
analyzes the two data streams thai come from the PCM 
interface board. The results of t his analysis consist mainly 
of call and alarm records, which are stored in an internal 
database before being forwarded to the central unit via 
the master CPU. 

If multifrequency signaling analysis is required, the slave 
module requires an optional digilal signal processing 
board. This board contains three digital signal processing 
units that ace identical lo the single digital signal process- 
ing unit on the PCM interface board. In reality, only two 
of the units are used to realize four multifrequency re- 
ceivers; the lasl one is a spare. The data to be processed 
is directly provided by the PCM interface board through a 
high-speed bus ( 20 Mbit s/s peak I, 

A very simple hardware slruclure and digilal processing 
based on a fast Fourier transform (FFT) algorithm ensure 
the detectors reliability. The efficiency of the detector is 
further increased by Ihe use of Ramming windowing and 
shifting the analyzed Spectrum lo minimize Ihe leakage 
errors resulting from Ihe finite length of the time record. 1 

The peripheral unit's application software has been de- 
signed lo be easy to adapt to the different signaling sys- 
tems that are in use around the world. The different soft- 
ware measurement modules can be linked differently to 
achieve Ihe desired results but I hey all use the same op- 
erating env ironment and services. This enables a rapid 
development process and ensures high software quality. 
Only the higher-level module used lo decode Ihe seman- 
tics of the signaling is developed specially for each signal- 
ing version. To simplify this process, this layer has been 
written using Ihe Specification and Description Language 
(SDL), a very high-level language. This language, specified 
by the CCITT, has the advantage thai it is well-known 
among signaling experts and allows reliable communica- 
tion between specifiers and designers. 

Finally, its physical dimensions make the peripheral unit 
suitable for simple installation in the 10-inch standard 
racks that are commonly found in central office premises. 

The Central Unit 

The central unit for the HP E350OA network monitoring 
system is an HP 9000 computer running the HP-UX oper- 
ating system, version 7.0 or higher. The system soli ware 
has been developed so that any member of the HP 0000 
family (Series 300, 400, or 800) can he used, depending 
on the size of the network and Ihe number of peripheral 
units required. The IIP E3500A network monitoring sys- 
tem peripherals can be grouped in clusters (up to a maxi- 
mum of 16 units on a single RS-485 bus) and each cluster 
is connected lo the central unit using a serial line. 

The central unit is responsible for: 

• Managing all of the connected peripherals 

• Collecting data from the peripherals 

• Processing the collected data to obtain quality indexes 

• Storing Ihe quality indexes and all the elementary data 
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Displaying Ihe quality indexes (and, if required, elemen- 
tary data) as required by the system operator. 
The central unit software uses a relational database 
(Oracle RDBMS Version 6.0 for the current release) for all 
of its system configuration and elaboration needs. In the 
following descriptions litis database is referred to as the 
"disk database", while "database" refers to a generic data 
base entity. 

The central unit software can l>e divided into three main 
parts: 

The communications soft ware manages the communica- 
tions between the central unit and the peripheral units. 
The elaboration software provides interpretation and 
analysis of collected data. 

The user interface allows control of the system and dis- 
plays network performance. The operator accesses the 
system through this OSF/Motif-style interface. - 

In addition to these main parts, there is a supervisor 
function that manages system behavior and resources. 
The following descriptions focus on the elaboration soft- 
ware (Fig. 4), to show how the performance required for 
the HI' E3500A network monitoring system was achieved. 

Elaboration Software 

In the IIP E3500A network monitoring system the data 
sent from the peripherals to the central unit is always 
packed in the same format: the call record. A call record 
Contains all Hie information about a single call attempted 
by a user of the monitored telephone network. It contains 
infonnalion such as: Ihe stall time of the call, dialed dig- 
its, duration, answer type, and so on. All of Ihe call re- 
cords coining from all of the peripherals are sent by Ihe 
communication software to the ELAB_QUEUE message 
queue. The ELAB process lakes each call record from 
E LAB. QUEUE and then: 

Kinds Ihe time slice, origin, and desi gnation of the call. 

Call Records Irom 
Peripheral Unils 

HP Real-Time 
Database 




Fig. -i. Simplified block diagram at the elaboration software 



• Classifies the call (determines whether the call is 
successful or unsuccessful because of caller behavior, 
network congestion, destination busy, or any other rea- 
son). 

• Updates the quality indexes for the current time slice, 
origin, and destination triple with the current call contri- 
bution. 

• Stores each (classified) call record and the updated quali- 
ty indexes in the disk database. 

To perform the first three tasks. ELAB must read the re- 
quired information (network topology, peripheral set de- 
scription and other network-related information) from the 
disk database, and then write to the disk database for the 
last task. About ten disk database queries (one of which 
is sequential ) are needed to complete Lhese tasks for a 
single call record. At the same time, for a given number 
of peripherals, large amounts of data are being entered 
into ELAB_QUEUE via the communication software (that is. 
from the peripheral units). For example, a typical system 
consisting of 20 clusters with a total of 100 peripheral 
unils must deal with about 300 call records per second. 
This is considered the largel level of performance for a 
large IIP iH.MHJ Model S.'15-based system and is based on 
experimental dala obtained from peripherals installed in 
the Italian telephone network. The size of a call record 
after the expansion performed by the communication soft- 
ware is 105 bytes. It is obvious that a consumer (ELAB) 
using the disk database cannot cope with a producer 
such as the IIP E3500A network monitoring system pe- 
ripheral units. 

The solution adopted uses the IIP Real-Time Database 1 
(IIP RTDB) as a cache memory before finally storing the 
dala in the disk database. IIP RTDB is a high-perform- 
ance real-tune database management system built on the 
HP-UX shared memory feature, which allows multiple 
processes to access Ihe database concurrently. 

The RTDB is initially created by the system manager dur- 
ing sysiem configuration. Using some offline utilities thai 
come with the system, the system manager can copy 
some of the tables required by ELAB from the disk data- 
base into Ihe RTDB. These are then loaded inlo memory 
at system startup. When Ihe sysiem is running, ELAB can 
read Ihe infonnalion ii needs for call record elaboration 
from the RTDB (C0NEIGJNF0 in Fig. 4), and write Ihe qual- 
ity indexes inlo the RTDB (INDEXES In Fig. 4). At a rate of 
300 call records per second or more, which would require 
al leasl 3000 database queries per second or more, the 
performance offered by the RTDB is far beyond current 
needs. By this method, Ihe database access requirements 
of ELAB are no longer a botlleneck for Ihe system. 

IIP RTDB is a memory-resident database, so there must 
be a process thai definitively stores its data in Ihe disk 
database. The process named FREEZY works in the back- 
ground, continuously scanning the RTDB INDEXES table. 
When il finds an entry (day, lime slice, origin, destination) 
in Ihe table that has been marked as CLOSED by ELAB, il 
freezes il in Ihe corresponding day table in the disk data- 
base as an entry consisting of lime slice, origin, and des- 
tination. The algorithm used by ELAB to mark an entry 
applies a user programmable lime window (whose span is 
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given in units of time slices) which moves on with new 
incoming call records. When a time slice TS slides 
through the lower edge of the time window, ELAB marks 
all the entries belonging to TS (the old time slice) as 
CLOSED and discards any further incoming call records for 
that time slice (if any). 

The only remaining problem is the call record storage 
process. Because of their lotal size — up to I Mbyte per 
day per peripheral unit, it is not possible to store all of 
the call records IB the memory-resident RTDB, and ELAB 
cannot write them directly into the disk database. The 
solution that was implemented uses a new process (CACH- 
ER in Fig. 4) and a virtual-memory -based algorithm. ELAB 
now receives call records from ELAB_QUEUE, elaborates 
each of them as quickly as possible thanks to the HP 
RTDB. and simply sends them to the new CAC.HER_0.UEUE 
message queue. CACHER is a very fast consumer, ll contin- 
uously checks the CACHER^QUEUE message queue, reads 
any call records that it contains, and stores them in 
memory. Only when it is not busy (that is, when there is 
nothing to receive from CACHER_QUEUE), does it free the 
call records and put them in the disk database. The fol- 
lowing listing is a nonformal pseudolanguage description 
of the CACHER.QUEUE algorithm: 

flag = WAIT; 
for (;;)( 

if (msgrcv|...,flag) == ENOMSG) { 

if (something in memory) free_and_store(...); 

else flag = WAIT; 

) 

else ( 
malloc_in_memory(...|; 
flag = NOWAIT; 

} 

} 

Since mallocl) works with virtual memory, the run-time 
storage limit for CACHER is only limited by the disk size. 

We performed a series of load tests on an HI' 9000 Model 
835 computer with 32M bytes of RAM. The following .set- 
lings were made: 

The queue size was modified to the maximum allowed in 
HP-UX (64K bytes, equivalent to two seconds fill time at 
300 call records per second). 

The semaphores and shared memory parameters were 
modified according to HP RTDB needs. 
The HP RTDB tables were LOCKED in memory to avoid 
disk swapping. 

The user was given L0CKRD0NLY and RTPRI0 privileges. 
CACHER was configured lo store call records in memory in 
lOOK-byte blocks and the following real-time priorities 
were given to the processes: 

Protocol processes: time-sharing priority 

Receiving processes: real-time priority 91 

ELAB: real-time priority 90 

CACHER: real-time priority 92. 

The system was then loaded with programmable bursts of 
call records and the test results are shown in the follow- 
ing table. 



HP E3500A Network Monitoring System Load Test Results on an 
HP 9000 Model 835 
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NRec = call records/burst 

Pause = time between two bursts in ms 

NLines = number of serial lines in the system 



Note that CPU load increases with throughput, while the 
disk use decreases because CACHER has less time left to 
store call records in the disk database. The queues never 
seemed to get full and the virtual memory usage can in- 
crease almost indefinitely, allowing it to follow peak 
throughput rates for a long time. From the table it can be 
seen that an HP 9000 Model 835 can manage a through- 
put of 250 to 300 call records per second, which could 
support a system containing 60 to 100 peripheral units. 

Quality Indexes 

Quality indexes must give an overview of network load 
and service quality. The procedure to compute them must 
deal with some basic requirements: 

• II must be simple for the system administrator to define 
and/or modify index names and definitions. 

• Indexes should give aggregate infonnalion. 

• The computing procedure must be able to manage physi- 
cal differences between network nodes (node main 
switching units can use different electrical models). 

• It must be possible to examine computed values for pos- 
sible network fault conditions. 

Computed values must match statistical significance crite- 
ria. 

A description of how each of these requirements was 
fulfilled is given in the following sections. 

Index Names and Evaluation Algorithms 

The definition and modification of index names and the 
algorithms used to define them were made easy to per- 
form and use by a programming approach. The user can 
describe indexes and (heir algorithms in a text file that is 
read and interpreted each time the system software is 
stalled. The programming language is simple to use yel 
powerful enough to allow arithmetic computations, vari- 
ables, and flow control by means of IF-THEN-ELSE and 
WHILE constructs. The individual fields of call records are 
available for computation as predefined variables. Vari- 
ables declared as indexes are automatically evaluated 
online for every call record received and subsequently 
stored in the system database. These elementary indexes 
consist of parameters that can be extracted directly from 
call records such as number of attempted calls, number 
of successful calls, and so on. 
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Aggregate Information 

The need 10 gel aggregate information — for instance, the 
mean duration of telephone calls between two nodes dur- 
ing a specific time period — was satisfied by introducing a 
second group of indexes. The algorithms to compute 
these compound indexes are called offline from the user 
interface and can use the values of the corresponding 
elementary indexes (recalled from the disk database for 
this purpose). 

Physical Differences 

Network pairs of origin link and destination are logically 
grouped in sets according to the signaling system 
adopted. The programming language takes this into ac- 
count and provides the class construct to match each set 
with the related description. When ELAB updates a set Of 
indexes, it uses the origin link and the destination node 
of the call record to index the proper class and the 
associated computing procedure. 

Network Fault Detection 

It is useful to have the system automatically detect possi- 
ble fault conditions within the monitored network and 
focus operator attention on those faults. A simple way of 
doing it is to compare each evaluated index with a prede- 
termined threshold value. Most indexes are defined so 
that faults are indicated by low values, so a possible fault 
will be linked to a value under the given threshold. How- 
ever, there is not always a clear distinction between ac- 
ceptable values and faulty ones. Therefore, it was decided 
to associate every index with two threshold values for the 
three following situations (lower to higher value): 

• Alert/Possible Fault 

• Wanting 

• OK. 

The value of the fault test is returned with the index val- 
ue after computation has been completed and is used in 
the display phase lo highlight possible problems. The fault 
thresholds for an index can be redefined within each 
class. 

Statistical Significance 

Phone call parameters (number a,K ' < lur^il ioi i ) and aggre- 
gate indexes (mean duration, total number of calls in a 
time period, and so on) can be seen as random processes 
with given characteristics ( unilateral exponential vari- 
ables, binomial variables, Poisson processes, and the 
like). Thus I he evaluated indexes can be used not only to 
see the state of the network at a certain lime in the past, 
but also as a means of forecasting its future performance. 
This is, of course, one of the most meaningful uses of the 



IIP E3500A network monitoring system in addition to 
network fault detection. 

To be able to use an index value as an estimate (accept- 
able to a certain extent) for the characteristic of the ran- 
dom process it is associated with, the index must match 
the criteria of probability theory. To get an estimate with 
a given probability of maximum relative error (relative to 
the theoretical random process value), the system has to 
monitor a minimum number of calls. 

This led to the introduction of two more thresholds for 
each index to cover the three situations: 

• Statistically unacceptable value 

• Low statistical significance 

• Statistically significant value. 

The intermediate le%"el was introduced to take into ac- 
count situations where a low number of samples deprives 
the index of its full statistical meaning but can neverthe- 
less signal a network fault. As for the index threshold, 
the value of this test is returned with the index value 
after the computation and is used in the display phase 
combined with the fault test value. Like the fault thresh- 
olds, the statistical thresholds for an index can be rede- 
fined within each class. 
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Absorption bands 50/Apr. 

Abstract data t>pe 32/Der. 

Access routines. HP Sockets tt-Dec 

Adapters. HP Sockets 9/Dec 
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Administration node. 

HP Sockets 15/Dec. 

Alarm monitor 40/Dec. 

Alarms 16. 32/()ct. 

ALC 30/Feb. 

ALC. sweeper 24/ Apr. 

Amplifier doubler. R-band 58/Apr. 

Amplifier doubler. V-band 56/Apr. 
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ASN.l 21/Dec. 
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Attenuators, programmable, step . 47/Apr. 

AUTOMAN keypusher 50/Oct 

ACTOTEST 49/Oct. 
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Basic Encoding Rules (BER) 21/Dec. 

BIOMON (backplane I/O 

activity monitor) 94/Oct. 

BIOS (Basic I/O System), 

Vec(ra486 83/Oct. 

Birefringcni crystals 46/Fel>. 
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Blood pressure 0, 25/Ocl. 

Bondless microcircuits 38/Apr. 

Bottom case assembly, HP 48SX . . 30/June 

Branch analysis 83/Apr. 

Branches. DSEE 78/JUne 

Breadboard system, microwave . . . 4 I/Apr. 

Break-even time (BET) 71/June 

Build managemenl 85/June 

Burst-mode read. Veclra 486 ... . Sl/Oct. 
Bus master 73/Oel. 
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Cache memory, Vectra 486 78/Oct. 

Cache simulator 95/Oet. 

Calculation (-valuator 42/Oct. 
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Calibration, lightwave 

analyzer 20, 34/Feb. 

Calibration, optica] power meter . 70/Feb. 
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Calibration, sweeper . 19, 21, 22, 26/Apr. 

Call record 60/Dec 
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Chromatic dispersion 9/Feb. 

Circular interpolation 32/Feb. 
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Code inspections 68/Oct 
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Communication model 16/Oct. 
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Compiler, NLS text 39/Oct. 

Compiler, user interface 57/June 
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Computer module 7/Oct. 
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Hypertext help system B3/.Iune 
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IP" amplifier 42/Apr. 

Indexes, network quality 64/Dec. 

In-process project retrospective 

reviews 73/June 

Input/output system, HP48SX 35/June 

Integral contacts 38/Apr. 

Integration, test system 53/Oct. 

Intel486 69, 78/Oct. 

Interface, parameter module .. 17, 19/Oct. 

Interfaces. HP 48SX 36, 37/June 

ISA (Industry' Standard 

Architecture 73/Oct. 

Isolator, optical 16/Feb. 
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Kermit protocol 36. 39/June 

Keypad, patient monitor 34/Oct. 

L 

Laser FM response 9/Feb. 

Laser source 59. 73/Feb. 



Lightwave component analysis, 

20-GHz 6/Feb. 

Lightwave multimeter 58/Feb. 

Lightwave receiver 19, 30/Feb. 

Lightwave source 7, 15, 29, 73/Feb. 

Lightwave lest set 15, 23/Feb. 

Lithium niobate 42/Feb. 

LI (amplifier 40/Apr. 

LO feedthrougli nulling 47/June 

Local oscillator, spectrum 

analyzer 50/June 

Localization 37/Oct. 

Loss measurenienls. optical 60/Feb. 

Low-band microcircuit 36. 39/Apr. 
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Mach-Zender interferometer 42/Feb. 

Magnetooptic isolator 46/Feb. 

Mainline 77. 84/June 

Manufacturing, HP 48SX 40/June 

Manufacturing, patient monitor . . . 52/Oct. 

Maps, HP-SI 28/Dec. 

Master CPU 60/Dec. 

Material flow, vertical 52/Oct. 

Measurement interface model .... 68/June 
Mechanical design, 

patient monitor 44/Oct. 

Memory architecture. Vectra 4S6 . . 79/Oct. 

Memory card and connector 32/.Iune 

Memory controller, Vectra 486 78/Oct. 

Memory inil Udizal ion, 

Vectra 486 90/Oct. 

Memory subsystem simulator .... 9f>/0ct. 

Message classes 16/Ocl, 

Message passing bus 8, 1 1/Ocl. 

Metrics database 55/Oct. 

Microcircuit design tecliniques . . . 36/Apr. 

Micro-DIN 87/Oct. 

Microwave design system 53/Apr. 

Mismatch error 28/Apr. 

Mixer, triple balanced 40/Apr. 

Modsplitter, microcircuit 36, 43/Apr. 

Modulator, optical IS, 41/Feb. 

Modulator, pulse 34/Apr. 

Module rack 7/Oct. 

Module specifications 53/Dee. 

Module tables 17/0ct. 

Monitor configuration table 17/Oct 

Monitor, patient 6/Oct. 

Monitor, telephone network 59/Dec. 

Multimeter, lightwave 58/Feb. 

Multiple equation solver 23/June 

Multiplying DAC 66/Feb. 

Multiprocessor system 10/Oct. 

N 

Network interface 12/Dec. 



Network monitoring system, 

telephone 59/Dec. 

North American dual-mode 

I-Q diagrams 66/Apr. 

NLS database 38/Oct. 

NLS tools 39/Oct. 

Nulling, LO feedthrough 47/.lune 

0 

Object types, RPL 8/.(une 

Open Dialogue. HP VUE 93/Feb. 

Optical launch measurement 10/Feb. 

Optical power measurements .... 58/Feb. 
Optical reflection and transmission 
measurements 9. 25/Feb. 

OSF/Motif, IIP VUE 90/Feb. 

P 

x/4 DQPSK modulation 65/Apr. 

Pac e pulse detection circuit 23/Oct. 

Parameter modules 7, 19, 47/OcL 

Parameterized ouler loop 13/June 

Patient monitoring system 6/Oct 

Patient simulators 5()/0ct. 

Perfonnance. HP Sockets Hi/Dec. 

Performance, sofi ware 65/Jime 

Performance tool quadrant 70/.Iime 

Performance, Vectra 486 92/Oct. 

Peripheral units 60/Dec. 

Persona] computer. Vectra 486 .... OW/Oct. 

Physiological calculations 40/Oct. 

Plotting. IIP 48SX 17/June 

Plug-in management, IIP4SSX 9/June 

PMON (process activity 

monitor) 92/Oct. 

Poiseuille's law -Il/Ocl. 

Polarization controller 17/Feb. 

Post-introduction product 

reviews 72/.Iune 

Power leveling, sweeper 24/Apr. 

Power measurements, optical .... 58/Feb. 

Power sensors, optical 63/Feb. 

Precision. HP-SL 48/Dec. 

Preprocessors. IIP Branch 

Validator 84/Apr. 

Printed circuit assembly. HP 4SSX . 29/.Iune 

Printhead control 28/Oct. 

Process specification, HP-SL 54/Dec. 

Producl development process .... 71/June 

Programmable-gain amplifier 66/Feh. 

Project management. DSEE 79/June 

Pulmonary vascular resistance 

(PVR) 41/OcL 

Pulse oximeter (SaO>) 6/Oct. 

Pump assembly 25/Oct. 
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QPSK modulation 67'Apr. 

Quadratic gradient constant 64/F eb. 

Quality function deployment 

(QFD) 74/June 

Quality, manufacturing process . . . 5-l/Oct. 
Quasi-elliptic low-pass filters -12. 4-1/ Apr. 

R 

R2 signaling system 59/Dec. 

Rack interface controller 20/Oct, 

RCS (revision control system) .... 84/June 

Real-time specifications. HP-SL . . . 40/Dec. 

Receiver, lightwave 19.30/Feb. 

Receiver, spectrum analyzer 45/June 

Recorder, stripchart 2(VOct 

Reference/trigger section, spectrum 
analyzer 53/June 

Refinement, HP-SL 38/Dec. 

Reflection measurements, 

lightwave 11/Feb. 

Remapping, Vcctra 4S6 89/Oct. 

Report generator. 

HP Branch Validator 88/Apr. 

Resolution bandwidth filters. 

sweeping 5-5/June 

Resting display 33/OcL 

RF deck, sweeper 8/Apr. 

RF lest set 13/Feb. 

Rigorous software engineering . . . 25/Dec. 

ROMPART 9/June 

ROMPTR 10/June 

RPI. operating system 7/June 

RUtile crystals 47/Feb. 

s 

Sati'llite module rack 7/0ct 

Scan table 20/Oct. 

Screencookbook 31/Oct. 

SCPI 16/Apr. 

SCPI driver 81/Feb. 

SCSI-2 (Small Computer System 
Interface). Vcctra 486 73/Ocl. 

Security, Veclxa 486 87/Oct. 

Self-test design, sweeper 17/Apr. 

Sequences, HP-SL 28/Dec. 

Serial disl ribution network (SDN ) . 1 1/Oct. 

Shadowing. Vectra 486 88/Oct. 

Signal processing, HP I1847A 74/Apr. 



SIMM (single in-line memory 



module) 78/Oet. 

Simulation tool 30VOct. 

Slave module 61/Dec. 

Slotline-to-microstrip transition . . . 32/Apr. 

SoftBench interface. HP Branch 

Validator 89/Apr. 

Software architecture. 

, n-i i> inoniiur 13/Oct 

Si.ftwiu.' i nnriguratiMii 

management 77, 79. S4/June 

Software defects 55. 58. 91/Oct. 

Software defect costs 55/Oct. 

Software defect profit loss 

calculation 57/Oct. 

Software development 

environment 84/June, 15/Oct. 

Software integration, 

HP Sockets 6/Dec. 

Software lifecycle 24/Dec. 

Software metrics 55, 58/Oct. 

Software performance tools ... 65. 70/June 

Solve, I1P48SX 22/June 

Source, lightwave 7, 15, 29. 73/Feb. 

Source match, changing 28/Apr. 

Source, millimeter-wave 50/Apr. 

Source, spectrum analyzer 52/June 

Source temperature control 16/Feb. 

Spectrum analyzer, 150-MHz 44/June 

Split-band amplifier 52/Feh. 

SS#7 59/Dec. 

ST segments 46/Dec. 

Standard display 34/Oct. 

Standard parameter 

interface 17, 19/Oct. 

Startup mid shutdown, 

I IP Sockets 14/Dec. 

State histories 41/Dec. 

Stale .specifications 38/Dcc. 

Strife testing, display 13/Apr. 

Stroke index (SI) 41/Oet. 

Stnicture chart 53/Uec. 

Structured analysis 53/Uec. 

Structured design 53/Dec. 

Sweep dynamics, spectrum 

analyzer 55/June 

Sweepers, to 50 GHz 6/Apr, 

Symbolic identification 16/Oct, 

Syntax checker 39/Ocl. 



System administration 93/June 

System integrator. HP Sockets 8/Dec. 

System invariants. HP-SL 37/Dec. 

Systemic vascular resistance 

(SVR) 41/OcL 

T 

TAB !Cs 41/June 

Tagged queuing TOvUct 

Task windows 35/Oci. 

Telephone network monitoring 

system 59/Dec. 

Test automation. HP Branch 

Validator 83/Apr. 

Test environment, automated 49/Oct. 

Test opportunities. HP Branch 

Validator 83/Apr. 

Test sets. RFand lightwave ... 13. 20/Feb. 

Testing, software 83/Apr., 91/Oct. 

Topcase assembly. HP 4SSX 26/June 

Transimpedanee amplifier 65/Feb. 

Translation tool 40/Oct. 

Transmission measurements. 

lightwave 11/Feb. 

Types. HP-SL 27/Dec. 

u 

Unequally spaced diodes 34/Apr. 

I'sability tests 31/Oct. 

User interface compiler 57/June 

User interface, lightwave analyzer 19/Feb. 

User interface, patient monitor ... 29/Oct. 

User interface, sweeper 12/Apr. 

V 

Values. HP-SI 27/Dec. 

Variable speed control 85/Ocl. 

Ventricular stroke work 

(LVSW/RVSW) 41/Ocl. 

Version control 77/June 

Virtual processor 15/Oct. 

Vision, automated 43/June 

Visual shell (vsh) 89/Feb. 

w 

Walk-off 46/Feb. 



© Copr. 1949-1998 Hewlett-Packard Co. 



December 1991 Hewlett-Packard Journal 73 



Part 3: Product Index 



Domain software engineering environment (DSEE) June 

HP 1 184GA ji/4 DQPSK I-Q generator Apr. 

HP 11S47A xft DQPSK modulation measurement soft ware Apr. 

HP 11982A lightwave converter Feb. 

HP 33324M attenuator Apr. 

HP 3332I5M attenuator Apr. 

HP33327M attenuator Apr. 

HP 3588A spectrum analyzer June 

HP 48SX scientific expandable calculator June 

HP8I21UM isolator Feb. 

HP 81310U isolator Feb. 

HP 81520A detector Feb. 

HP 81521B detector Feb. 

HP 8I53A lightwave multimeter Feb. 

HP 8153QA power sensor Feb. 

HP 8 1 531 A power sensor Feb. 

IIP 81532A power sensor Feb. 

HP 81536A power sensor Feb. 

HP81533A head adapter Feb. 

HP 8 1551 MM laser source Feb. 

HP 81552SM laser source Feb. 

HP S1553SM laser source Feb. 

HP S1554SM laser source Feb. 

HP 88420A lightwave test set Feb. 

HP 8.3421 A lightwave source Feb. 

1IP83422A lightwave modulator Feb. 

HP 83423A lightwave receiver Feb. 

HP 8342 IA lightwave CW source Feb. 



HP 8342-5A lightwave CW source Feb. 

HP 83557A millimeter-wave source module Apr. 

HP 835684 millimeter-wave source module Apr. 

HP 8360 Series synthesized sweepers Apr. 

HP 83G20A synthesized sweeper Apr. 

HP 83621 A synthesized sweeper Apr. 

HP 83622A synthesized sweeper Apr. 

HP 83G23A synthesized sweeper Apr. 

HP 83624A synthesized sweeper Apr. 

IIP 83630A synthesized sweeper Apr. 

HP 8363IA synthesized sweeper Apr. 

HP 83640A synthesized sweeper Apr. 

HP 83042A synthesized sweeper Apr. 

HP 83650A synthesized sweeper Apr. 

HP 83<)f>lA synthesized sweeper Apr. 

HP 83S10A lightwave signal analyzer Feb. 

HP 8703A lightwave component analyzer Feb. 

HP Branch Validator Apr. 

HP ( 'omponent Monitoring System Oct 

IIP K3500A network monitoring system Dec. 

HP GlancePlus/UX June 

HP GlancePlus/V lune 

HP GlancePlus/XL June 

HP Sockets Gateway Dec. 

HP Software Integration Sockets Dec. 

HP Vectra 486/25T Oct 

HP Vectra 486733T Oct. 

HP VIE 1.0 Feb. 
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